What is the managment overhead of decentrilized version control?

[John Arbash Meinel]

Adeodato Simó wrote:
> * John Arbash Meinel [Wed, 21 Jun 2006 08:16:59 -0500]:
> 

...

>> I have it working with standard opensshd, so I'm not sure why it isn't
>> working for you. But it is definitely something that we want to support.
> 
> Isn't this all solved with ACLs? I need to set up a shared repository
> soon, and was counting on ACLs saving my day. Worked fine in the tests I
> did, with bzr push.

Well, I'm the one who wrote the permission preserving stuff in bzr.
Basically it just checks the permissions of the original .bzr/
directory, and tries to apply those to all directories underneath (and
files with a-x).

So right now if you do:
cd /shared/branch
chown -R .group .bzr
find .bzr -type d -print0 | xargs -0 chmod 2775
find .bzr -type f -print0 | xargs -0 chmod 664

Bzr should try and preserve 775 on all directories, and 664 on all
files. And if you use the sticky group bit, everything should be created
in the right group.

Now, it might be the case that I didn't properly test for the sticky bit
staying set for directories.

I messed up permissions with rsync, so it is possible that masked the
permission problems with regular 'bzr push'.

I just did another test, and found that it is indeed broken. Foolish sftp...
https://launchpad.net/products/bzr/+bug/50568

(The sgid bit was already set. If you are going to strip my chmod, at
least leave the sgid bit set on the other side)

Anyway, we are looking at refactoring our put + chmod stuff anyway,
since we are trying to decrease roundtrips and os call overhead.

The biggest problem is we are screwed either way if the remote sftp
default umask is 0022. If we just mkdir() with a mode, it will strip off
the group write bit. But if we do a chmod, it will strip off the sgid bit.


It seems that there is a patch to openssh:
http://sftplogging.sourceforge.net/
which allows for setting umask.

But right now openssh + sftp seem broken in such a way that we are
always screwed. In the short term you can change the sftp sub-process so
that it sets the umask. I've done this in the past:

sftp-wrapper.sh:
#!/bin/sh
# Just run sftp-server with the correct umask
umask 0002
exec /usr/libexec/openssh/sftp-server

And then change the line in /etc/ssh/sshd_config to use sftp-wrapper.sh
instead of /usr/libexec/openssh/sftp-server as the 'sftp' subsystem.
(naturally the paths must be correct on your system).

John
=:->

> 
>> The only times I've found it to fail was when I was using rsync to push
>> my branches, which caused the remote end to take on the local
>> permissions, rather than the shared remote permissions.
> 
> Right, I also suffered that. :)
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060621/be21bcea/attachment.pgp