CVS Repository problem

[Kevin Buettner]

On Oct 6, 12:19pm, Stephen Smith wrote:

> Reason #1 is that I often work from home and I am the only one
> working on one of the modules.  Since I have a SLOW DIALUP, it is
> easier to move the repository with me.  I often compare versions, so
> snapshotting isn't preferable.

We have a number of remote employees where I work too.  (In fact, I'm
one of them.)  One of the things that some people do is to rsync
(one direction) the master repository to a local repository that
they use for doing ``cvs diff'', etc.  I haven't tried this yet,
but it does sound like a good idea.  There are many times that I
would be more productive if I had a fast local repository that I
could do read-only operations against.

Commits always take place against the master repository.  This is not
usually a problem though in my work environment since commits are
considered "heavy-weight" operations anyway.  I.e, changes that we
want to commit often have to go through peer review first which can
take days (or even weeks) to get, so it doesn't matter if it takes a
few extra minutes to do a commit.  There are folks who have blanket
write privileges, but even these folks often send out their changes
for peer review rather than just committing them.

If you want to get a feel for what this review process is like, take a
look at the gdb-patches mailing list at:

    http://sources.redhat.com/ml/gdb-patches/

Basically, all patches committed to the main branch of the repository
must be sent to this list.  Those with blanket write privs or
maintainers of a certain area will send a patch representing the
change that they committed immediately after the commit.  Other
folks who need approval before they commit will send an RFA (request
for approval) message and then wait for approval.  Often times, the
maintainer in question will ask that some changes be made prior to
granting approval.  Sometimes, maintainers will send out an RFC
(request for comments) patch for changes they've made prior to
committing something in order to solicit feedback for a potentially
destabilizing change.

These procedures can slow down the pace of development, but from what
I've seen, the quality of the code ends up being much higher.  Also,
anything goes if you're working on a branch; so it is possible to work
on a branch a while and then when things are ship-shape, create a
patch and go through the review process.  (To the best of my
knowledge, no one does this on the external repository though.)

(Okay, that was a pretty severe digression.)

> Reason #2 we are going to have to rebuild the machine the trees are
> currently on and for security reasons it would be better to have
> them in separate trees with different permissions.

Okay.  I'm not sure, but it may be possible to implement some CVS checkin
scripts which would do the necessary checking.  That said, it may just
be easier to do as you plan.