I've seen a number of blog posts, and have experienced for myself, that Mercurial does not preserve the permissions on files pushed from one repo to another. Does anyone know of a Mercurial extension that would preserve the permissions? I'm assuming it can't be done with a hook, because what does a hook know about permissions at the originating repo?
Requested elaboration:
If the only change to a file is a change in permissions (e.g., chmod o+r filename), attempts to commit the file fail with a message saying that the file has not changed.
If I commit a file with permissions 600 (rw-------), then clone the repo, the same file in the clone has permissions 664 (rw-rw-r--):
: nr@yorkie 6522 ; hg clone one two
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
: nr@yorkie 6523 ; ls -l one two
one:
total 4
-rw------- 1 nr nr 8 Aug 18 21:50 foo
two:
total 4
-rw-rw-r-- 1 nr nr 8 Aug 18 21:51 foo
This examples shows that hg clone does not preserve permissions, but hg push does not preserve them either.
In my application, one repo is on a publically accessible path, and it's of major importance that
Multiple users have the right to change the repo
Files in the public repo become readable only when explicitly made readable.
It looks like it can be done using hooks and an auxiliary tool (and a little chewing gum and baling wire):
Get David Hardeman's Metastore, which saves and restores file metadata.
Alter the sources so it will ignore directory .hg as well as .git.
Use the following Mercurial hooks:
precommit.meta = metastore -s
changegroup.update = hg update
update.meta = /usr/unsup/nr/bin/metastore -a
You have to add the .metadata file to the repo.
This lashup will work most of the time, but if you change only permissions and want to propagate it, you'll have to run metastore -s in order to push those changes into the .metadata file where hg will see the change; otherwise the commit thinks nothing is new.