I used robocopy like this:
robocopy D:\123 D:\456 /e /copyall
than I changed the permissions of folder D:\123(change ACL,include all files and subfolders), I want to copy the new permissions of folder D:\123 to folder D:\456(include all files and subfolders). so I used robocopy like this:
"robocopy D:\123 D:\456 /e /copy:sao"
Update permissions(ACL) for all files succeeded,but the permissions(ACL) of the folder update failed,the permissions of all folder is not changed.
How can I update the permissions(ACL) of folders?
You can find complete information about why coping folder permissions can't work when there's no modifications in files and folders and why permissions on files are not copied in older versions of Robocopy.
https://techcommunity.microsoft.com/t5/storage-at-microsoft/robocopy-mir-switch-8211-mirroring-file-permissions/ba-p/423662
When I wrote the “security copy” part of Robocopy on 22 May 1997, I
chose to do this for performance reasons, to keep Robocopy times for
large trees down. This was an adequate implementation for most
peoples’ needs at the time. Also, another reason I chose to do things
the way I did, is that setting security on directories is sufficient
for most people. Setting security on a file-by-file basis is a more
granular approach, for sure, but incurs a larger maintenance overhead,
perhaps too much for many users.
Try to use this command to maintain two folder in sync including security information (ACL)
So, to maintain two trees in sync, including their security, using
Vista’s Robocopy, you can use the following as your regular Robocopy
command:
ROBOCOPY <source> <target> /MIR /SEC /SECFIX
Related
File templates for WebStorm can be placed in the config/fileTemplates directory of the local WebStorm settings folder.
In addition to the templates stored there, I have a couple of file templates for our project that are in the project SVN repository. I want WebStorm to also offer me these templates.
Is there a way to tell WebStorm to use a specific folder in my working copy on top of the usual fileTemplates directory?
I could find some hints, but they appear to be dead-ends (or maybe I'm missing something):
The documentation on sharing templates makes this sound very manual (as in, moving files around). This is not a viable approach, as the template files might be updated any time. I do not want to preemptively copy the files around after each of my daily working copy updates, just in case on of them has changed (nor do I want to watch out for changes to the templates folder - I want WebStorm to catch up on these udpates on its own).
The article on file and code templates refers to per-project templates that "can be shared among the team members". This sounds like the right thing, except that they have to be placed in the .idea folder (the folder with the project file(s)). As I'm working on a huge project with many submodules, each team member (of several dozen devs) is only interested in a different subset of the overall project, so everyone has their own .idea folder that is not committed to version control.
The article on project and IDE settings indicates that (only?) "Locations of the config, system, plugins directories can be modified in idea.properties file."
We have a Mercurial repository with many projects, each resides in its own directory:
- Main Repo
- Project A
- Project B
- ...
Each of the projects is self contained and must reside in it's own directory, but there are some common files that should be similar between projects.
For example, some projects are websites, and they share a common javascript library we develop. When changing the library in one project, we would like it to change in other projects too, but the file must reside in each of the projects.
I read about sub-repos but they don't seem a good solution for this.
Is there a way to accomplish this in Mercurial?
You are looking for a feature for keeping the same file version in multiple places, also known as file cloning or file sharing in other types of source control, like Sourcesafe or Vault. There is no mechanism like this in Mercurial. Every file is a single entity with a single location.
The first solution you have is to keep the common libraries in a separate place. You need a single copy that can be accessed by all your projects. It does not matter if you use sub-repos or not, they can all be in the same repo, as long as your folder structure includes everything, but sub-repos can be easier to manage if your projects are not related.
The other solutions you have could be to state an internal policy to always sync and commit the common libraries manually (which I do not suggest as it is error-prone and requires effort), or to create a script, either as hook or not, to sync your files, before a commit or after an update (which is more tedious to establish and maintain anyway)...
Conclusion, go for the separation of your common libraries. You'll be glad you spent the extra time to set everything up correctly from the start.
Under Unix you could use soft-link (ln -s) for shared files and Mercurial will detect / save / create them. Just don't use absolute or empty path.
With Windows symbolic links won't work:
Tracking hard or symbolic links with mercurial on Windows
Bug 1825 - junction/parse point for windows directory symlinks
In my experience (local Linux repository) using symlinks to handle shared files works but it's usually better to create a library that contains the common files.
Even if you have one repository for all your projects, it is advised to have a separate library/tool/etc. repository(ies) for the common code(s).
The way you can "use" this code inside your project will then heavily depend on your technology and infrastructure: java/maven/ant world, linux distrib, ruby gems etc. You will generally have some kind of "dependencies specification" language where you can specify that you need such and such library. In a Gemfile for rails, using autoconf for C/C++ etc. Most of the time you can also specify a specific version (or greater than etc..) which allows taking care of API changes.
Basically it is not advised to solve this issue at SCM level but instead to use the right framework for decoupling your common code from the projects repositories.
There are one or two files, like .hgignore, which I generally want to be the same in each of a bunch of projects.
However, the nature of these files means that I can't simply move them to a common shared project and just make the other projects depend on that project. They have to be inside each project. Symbolic links are not an option either because some of our developers use Windows.
How can I share these files between repositories and have changes propagated across (on my local machine, at least)? I'm using Eclipse.
For your specific case of hgignore you can put an entry like this in each project's .hg/hgrc file:
[ui]
ignore.common = ~/hgignore-common
If you you know your common library will always the in the parent directory, as is often the case with a subrepo setup you could do:
[ui]
ignore.common = ../hgignore-common
or if you know it will always be in a sibling directory of project checkouts you could do:
[ui]
ignore.common = ../company-wide-defaults/hgignore-common
Unforunately there's no absolute way to reference a file that's valid everywhere, but you can at least to to a point where on your machine all your checkouts are referencing a common ignore.
Hardlinking instead of copying the relevant files sort of works with Eclipse - although you have to refresh each of the other projects to get it to pick up the change. However, you can configure Eclipse to watch the filesystem and automatically refresh whenever it needs to - I recommend this.
It does not work by default with Emacs, because Emacs breaks hard links (which is normally the right thing to do, but is not what you want in this case). However, you can disable this behaviour for multiply-linked files with (setq backup-by-copying-when-linked t).
My team is switching to Mercurial. Our projects all have a config file (web.config or app.config, and a few bat files as well - we are a C# shop). These files need to be part of the repository. When a developer clones the repository, local changes are needed to their config files to get them working. For example, a project's config file may need a connection string to the developer's database, or other environment-specific info. We don't want these changes ending up in the repository. And from time to time we do make changes to these configs that do need to get into the repository and distributed to the team and eventually the customer.
What is the easiest way for us to configure or use Mercurial so that these files are not getting committed by accident? I would like to be forced to make an explicit commit of such files, yet merges from the repo would automatically come down in updates.
This has to be a problem someone else has faced, but as Mercurial newbies we are all at a loss for the best solution.
Edit:
A similar question that may share some common solutions, but is not the same as this question, can be found at: Conditional Mercurial Ignore File
I am including this in case that other question might provide the answer you are looking for.
The typical way to handle this is to store templates for the configuration files in your repositor, and add the actual configuration files to the ignore list in Mercurial.
This way, you have pristine, unmodified, copies of each configuration files available at all times, even for new developers who clone from scratch, but in order to make the configuration files usable, you need to make a local copy of it to the actual configuration file name, and modify the file. You could also use compare/merge programs, such as Beyond Compare, to compare a new version of the template file with your local copy of an older version, to see what changed, and add in the missing bits.
If you need to hard prevent committing the actual configuration files, you need a pre-commit or pre-push hook that does this.
In your .hg/hgrc file do this:
[defaults]
commit = -X Projectname/web.config
(assuming "ProjectName" is the project subdir)
Edit:
Also, if you're using Tortoise HG - add this as well:
[tortoisehg]
ciexclude = Projectname/Web.config,Projectname/App_Data/DBFile.mdf
(by the way mind the FORWARD slash in folder-path! Even on Windows!)
I am writing a set of django apps and would like to use Hg for version control. I would like each app to be independent of the others so in each app there may be a directory for static media that contains images that I would not want under version control. In other words, the binary files would not all be in one central location
I would like to find a way to clone the repository that would include copies of the image files. It also would be great if when I did a merge, if there were an image file in one repo and not another, that there would be some sort of warning.
Currently I use a python script to find images and other binary files that are in one repo, but not the other. But a lot of people must face this problem, so there must be a more robust and elegant solution.
One one other thing...for reasons I do not want to go into, usually one of my repos is on a windows machine, and the other is on Linux. So a crossplatform solution would be nice.
Since Mercurial 2.0 the extension largefiles is now included in the main distribution. That extension keeps and manages large files outside of the "normal" repository in a way that you get the benefit of DCVS but without the benefit of exponential size and processing time growth.
Other extension that work along similar lines are SnapExtension and BigFilesExtension. However, those two are not distributed with Mercurial (you have to get them manually).
Mercurial can track any kind of file, for binary files if something changes then the whole file gets replaced not just the changes.
On the getting a warning if one repo doesn't contain a file, that's kind of the point of a DVCS is that the repos are related but are autonomous. You could always check and see what files were added during a synch or merge operation.
The current Mercurial book (by Bryan O'Sullivan) says, that Mercurial stores diffs also for binary files. How efficient this is, obviously depends on the nature of changes to binary files.