[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locks on CVS

From: gabriel rosenkoetter
Subject: Re: Locks on CVS
Date: Wed, 8 Aug 2001 01:36:39 -0400
User-agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 12:51:51PM -0400, Derek R. Price wrote:
> I'm not totally sure I understand what you're asking, but you might be
> looking for the setgid bit.  Something like, `find $CVSROOT -type d |xargs
> chmod g+s' should do the trick.
> Use at your own risk and all that.  Reading the fine man pages on chmod (re,
> in particular, setgid) might help too.

I'm not sure this will actually fix anything under Linux, as I don't
recall whether or not it (well, actually ext2fs) actually Does the
Right Thing wrt setgid bits on directories and file (re)creation.
I have a sinking feeling it does not, though. Even if it does,
isn't CVS doing something explicit here to change ownership if it
changes merely by running cvs edit as a client?

The real solution is probably to tell Linux's silly one-group-per-user
system to go blow (which won't fix everything, since the locked or
cvs edited files will get chgrp'ed to your standard users group, but
at least it won't leave you with files useable only by a single user),
then either institute some newgrp (or does Linux use sg?) usage in
your users' .login files on the cvsroot or perform some truly evil
magic in ${CVSROOT}/CVSROOT/loginfo. Actually, this isn't hard;
it'd be easy to keep track of what group should own which module,
and which module a file has just been checked into is readily
available to something called from loginfo. If it isn't readily
evident when you look at how loginfo works, drop me a line (privately)
and I'll whack out some pseudo-(read, Perl)code to do it.

Actually, if you do the loginfo dance, you probably don't need to go
and change Linux's brain damaged grouping system. But you should
anyway. ;^>

       ~ g r @

reply via email to

[Prev in Thread] Current Thread [Next in Thread]