1

Please help me with understanding the mechanics behind Mercurial in combination with ACL.

Our team uses Mercurial as a versioning system. The setup is very simple: two developers (one linux, one windows), remote repo (linux). Every time, the windows user W checks in modifications and the linux user L wants to pull afterwards, the following error messages (depending on the altered file(s)) are displayed:

pulling from ssh://user@domain.com
searching for changes
adding changesets
transaction abort!
rollback completed
abort: stream ended unexpectedly (got 0 bytes, expected 4)
remote: abort: Permission denied: /repopath/.hg/store/data/paper/tmp.txt.i

This is because the file access is handled by linux's ACL lists. After the ACL permissions are corrected with the setfacl command, everything runs smooth and L is able to pull. Even if W clones the repo with correct permission, the (new/ modified) files in the .hg directory have the wrong (default) permissions. The parent folder of the repo has the correct permission set, so I don't know from where those permissions are inherited.

Did somebody face similar problems? Thank you in advance!

Eric
  • 1,594
  • 1
  • 15
  • 29

3 Answers3

1

On my Linux box I had to set the sticky bit for group permissions. Essentially when you create a directory that will become a mercurial repository you need to use chmod g+s <repoDirectory> That will force anything created under that directory to have read/write/execute for group members regardless of what their defaults for file creation are. I was using standard Unix groups instead of ACL lists so I'm not sure how this will work out for you.

Eric Y
  • 1,677
  • 1
  • 12
  • 17
1

When creating new files inside .hg/store Mercurial copies the (classic) file permissions from the .hg/store directory itself and uses the user/group of the writing user unless overridden with something like the sticky group bit (as @Eric Y) mentioned. When modifying one of those files it retains the existing ownership and permissions if your user's umask allows it.

To my knowledge Mercurial does no special handling of file system level ACLs -- almost no tool does, which is why the ACL system also includes inheritance rules, where directories have their own ACLs and also have default ACLs that are inherited by newly created objects inside that directory -- maybe you need to look into setting the repositories default ACL in addition to setting its ACL.

That said, are you sure you really want to be using ACLs? If you're already using them and familiar with them that's great, but if you broke them out just to get 2-user-access working in Mercurial then you're betting off using a dedicated group (like developers) and the sticky group bit or using a single shared ssh account dev@unixhost with separate ssh private keys for each (see the SharedSSH page in the Mercurial wiki for an example).

ACLs are very powerful, but seldom necessary.

Note to other readers: Nothing we're saying in this question has anything to do with Mercurial's ACL Extension -- that's within Mercurial and this is file system ACL level stuff.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
0

There's only releases for Debian-based systems (like Ubuntu), but you should check out mercurial-server. It handles access control for Mercurial repos in a flexible manner, but outside of filesystem ACLs.

robert
  • 33,242
  • 8
  • 53
  • 74