On Tue, Oct 23, 2001 at 03:01:48PM -0700, Glew, Andy wrote: > "cvs ci" seems to change the file permissions, > removing group write, if keywords are expanded. > It does not if no keywords are expanded. > [...] > Have set umask to 002, so that most operations > make files group read write. > E.g. cvs co, cvs update, etc. do.
Weird. Are you *sure* the umask is 002? Here are some reasons it might not be: - Users' .profile's overriding your default - People run "cvs ci" via a script that's messing with the umask - commitinfo or other triggers (not sure if this could have an effect, but it's worth checking) - If you're using the watch/edit stuff, maybe that could affect it? - A local patch to CVS > Using cvs 1.10.8 > on RedHat LINUX 2.2.16-3smp > (maybe should be upgraded, but I am > not root) For testing, you could always build 1.11.1p1 for installation into your own space: configure --prefix=$HOME/cvstest If it fixes the problem, you'll have a better chance of convincing the sysadmin to upgrade the official installation. > Yeah, I know, keywords cause lots of other problems. > I may be better off without them. They can cause spurious conflicts when merging, but those can be avoided if I recall, and keywords certainly have their uses. The ones to avoid like the plague are: - $Log$, because its conflicts are particularly hard to resolve, and because it's redundant given the ease of running "cvs log" - $Header$, because it'll cause a whack of conflicts if you simply move the repo (the repo's full pathname is included in its value) > [*] if you must know, the reason that I want files to be > group read write is that we are experimenting with > pair programming, where two people work on the same > files, in the same directory, together. It is a pain > to have to constantly chmod g+w after having done > a checkin. > I know that many folks disapprove of two people > working in the same directory. Well, as I understand pair programming, the members of the pair still don't do that. *One* person does the actual typing; the other kibbitzes. The permissions problem arises from the fact that the two can switch roles fairly often. The reason for avoiding shared sandboxes -- that the sharers can stomp each others' changes -- doesn't apply. As a side effect, the paired-programming discipline imposes a (people-level) locking scheme on the members of the pair, which prevents concurrent writes. So the prohibition becomes: don't share sandboxes *between pairs*. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED] | | / The world has been attacked. The world must respond ... [but] we must be guided by a commitment to do what works in the long run, not by what makes us feel better in the short run. - Jean Chrétien, Prime Minister of Canada _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs