cvs ci removes group write permission if keywords expanded

[Glew, Andy]

I just encountered a minor problem with
file permissions in CVS apparently caused 
by "cvs ci" and keyword expansion.
I worked around it, but wonder if there 
is a better way. I have looked in the manual
and FAQs, but see nothing pertinent.

BRIEF:

"cvs ci" seems to change the file permissions,
removing group write, if keywords are expanded.
It does not if no keywords are expanded.

DETAIL:

Using cvs 1.10.8
on RedHat LINUX 2.2.16-3smp
(maybe should be upgraded, but I am
not root)

Working on a system where we want all files
to be owner read write and group read write.
(It's inconvenient if not[*]; yes, I know that 
I can add to build scripts.)

Have set umask to 002, so that most operations
make files group read write.
E.g. cvs co, cvs update, etc. do.

However, cvs ci changes the file permissions
to owner read write, group read-only (not group write),
if there is a keyword in the source file that is
expanded with a new value as a result of the checkin.

As I mention above, this is inconvenient.

I worked around it by removing keywords.
Is there another way?
Why is cvs ci ignorng the umask when 
expanding keywords?


OTHER RELATED STUFF

==> Keywords 

Yeah, I know, keywords cause lots of other problems.
I may be better off without them.  

I just regret losing 
a tool of mine that embeds version info in all binaries,
so that any can be reconstructed. As currently written,
this tool depends on keywords.  I can probably change
it to extract versions itself from CVS.

==> Pair Programming

[*] 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.  I do, or used to, but
pair programming seems to be an exception.  And, overall,
pair programming looks like a good idea.