Ubuntu: Jaunty
Mercurial: 1.3.1
Access: ssh (users john and bob)
File permission: -rw-rw---- 1 john john 129276 May 17 13:28 dirstate
User: bob
Command: 'hg st'
Response:
**abort: Permission denied: /our/respository/.hg/dirstate**
Obviously mercurial can't let bob see the state because the file it needs to read belongs to me.
So I change the permissions to allow bob to read the file and everything is fine, up until I next try to do something, whence the situations are reversed. Now he owns the file and I can't read it.
So I set up a "committers" group and both john and bob belong to the group, but still mercurial fiddles with the ownership and permissions whenever one or other commits.
Furthermore whenever one or other of us adds a file to the repository the file is owned exclusively by the committer. That开发者_开发知识库's fine by me since I'm familiar enough with chmod but it presents a major problem to bob when I neglect to grant him permission. I guess we just need a post-commit hook for that; but just to include this symptom...
How do we configure it so two different logins in the same group can commit to the same repository over ssh?
You need to set the "group sticky bit" on all the relevant directories. That permissions bit says that any file or directory created in those directories should have group ownership of the parent directory's group, not of the creating user's primary group.
You can set things right by going to the top level of your whole repo (hg root
) and running these commands:
chgrp -R committers .
chmod -R ug+=rwX .
find . -type d -print0 | xargs -0 chmod 2775 # or 2770 if other can't read
That first command gives group ownership back to committers
for all files and directories. The second command makes sure owners and group members can read and write all files and directories and that they can descend all directories. The third command lists only the directories (omitting files) and then sets the stick group bit on them. After you're done the permissions for directories will look like: rwxrwsr-x
You only have to do this once, and if you do it before creating the repo you don't need to use find at all since the sticky group bit will be inherited by all directories. It was done the same way for CVS and svn back in the olden days.
using unix groups: see the filesystem method here.
Long term the sticky bit solution didn't work either.
What has worked is putting the chmod/chgrp commands into a bash script and teaching the designer how to run it.
#!/bin/bash
chgrp -R foo /foo/development/templates
chgrp -R foo /foo/development/media
chgrp -R foo /foo/development/static
chmod -R g+w /foo/development/templates
chmod -R g+w /foo/development/media
chmod -R g+w /foo/development/static
精彩评论