RE: cvs commit/up's change file ownership in working dir.

[Patton, Matthew E., CTR, OSD-PA&E]

Classification: UNCLASSIFIED

> > If I check out stuff into /etc (or /var/www if you like) as root,
> 
> You're foolish; you should never run CVS as root.

er, why not? In client-mode? Right now I'm not using it under sudo but that
is the end goal so that only "cvs up" is allowed to be run as root by an
otherwise non-privileged uid. Are you telling me CVS is so bug-ridden that
it's untrustworthy? That despite the legions of problems, practically the
entire opensource movement uses it? and often in pserver mode (which runs as
root I might add - not that it necessarily needs to most of the time but
nobody has written any examples I've seen that didn't have it running as
root) no less? Come on now...

> CVS is a revision
> control system, it is *not* a complete file system manager.  

huh? A file system is nothing but a collection of files in a hierarchy. I
don't use CVS to manage my binaries (though I easily could and it would be
right useful actually - screw RPM), just some configuration files. The
active set is nothing more than a checkout of the repository that is never
edited in-place. How does this diverge in any way from CVS' design and
normal use?

> You should
> check out into a working directory and include a script (or a 
> makefile,
> or whatever) that can be run to move the files into the correct places
> and set the ownership and permissions correctly.

I already said I could run mtree after a checkout to set perms but I
(incorrectly) wanted to avoid that. You're right and I'm wrong.

In keeping with the unix tradition of 1:1=task:binary lets strip out every
last chown/chmod out of the CVS codebase as it relates to checkin/out of
user files (house-keeping stuff I can't comment on just yet) and deep-six
the PRESERVE_PERMISSIONS code since it really is none of CVS' business;
past, present or future. fopen(2) is all we need, right? So in addition to
my patch it looks like we might need to yank the odd line from checkin.c.
client.c has this change_mode() which is called once in client.c and
server.c that looks suspicious and probably a few others that seek to modify
permissions.

I can happily live with consistant refusal by CVS to muck with file
ownership and modes besides honoring umask&CVSUMASK. I just don't like
inconsistant behavior.