> I hope this isn't an oft repeated questions I've searched and found some
> stuff but not really enough to settle my concerns. I've a server with
> limited disk space and a large amount of files in a repository that
> various users need to work on. As such I've created a single working copy
> on the server for them to use and have also been asked to write a shell
> scripts that will get the files to a users workspace (essentially their
> home directory), move/add the files into the working copy when they are
> done and to add the files to the remote repository (This is kinda stupid
> but I couldn't really talk them out of it). This is all on a AIX unix
You really can't share a wc between multiple users. Obviously they can
try to edit the same file and clobber each other, and when they do go to
do a commit to the repository, the repository won't know who actually
did the commit. Also if two people try to commit, update, revert, or
whatever at the same time, you're going to clobber the wc.
> There are --I don't think surprisingly-- file permission problems and I'm
> wondering the best approach to this. What I've done is to require all
> users to be part of the same group that owns the local working copy, I've
> set the sticky bit on the directories to that group. In my shell scripts
> I've set umask to 002 and am copying existing files to the working copy
> and doing chmod=+rw.
> My questions are:
> Would it be wiser to set up the shell scripts to run as suid of the actual
> owner of the local working copy?
IIRC, shell scripts can not be suid, only binaries can.
> Subversion doesn't seem to notice acl changes on a file is this by design
> and why?
> Is my approach completly borked and if so is there a better one?
Yes, it is completely borked. The better way is to buy some more disks
( they are dirt cheap these days ) and give each user their own wc.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Feb 24 17:09:56 2006