Re: cvs ci removes group write permission if keywords expanded

[Eric Siegerman]

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.        address@hidden
|  |  /
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