Re: Can I do this?

[Kaz Kylheku]

Matt L <address@hidden> wrote in message news:<address@hidden>...
> I'd like to take an existing CVS; back it up and clean all of the CVS 
> specific files and dirs from it.

This is mostly done using ``cvs export''; which behaves like checkout,
but removes the CVS administrative directories. You still get things
like .cvsignore files which are CVS specific.

> Then I'd like to start with a clean 
> import and branch the code into seperate alpha beta and gamma branches 
> which would be held in directories named as such below $CVSROOT.  If that 
> is possible I would then like to maintain different permissions for alpha 
> beta and gamma code so that only admins are permitted to merge to and from 
> the gamma code branch but all others may read it and also commit to alpha 
> and beta directories.

By doing this you are effectively switching to a distributed model.
There are two teams (gamma gurus versus everyone else) and these two
have separate CVS repositories.

The only support in CVS for this type of model is vendor branching.

> I'm under the impression that CVS branches are kept together with the trunk 
> code and the differentiation is made by CVS itself so that it is 
> transparent to the user unless they CO the branch into a seperate 
> directory?

That is correct; the versioning dimension is projected into the same
spatial area of the filesystem. Only one version of a file is selected
at a time, and all the versions map to the same pathname. Moreover,
all of the versions are kept in one history file in the repository
which has but one set of operating system permissions.

>  would like to maintain an alpha,beta,gamma directory 
> structure so that the branches are clearly defined for those working on the 
> code and this seperation might also help with permissions.

People can do this locally by checking out different branches into
different sandboxes.

Commit permissions can be managed with server-side scripts. Look up
commitinfo in the CVS manual.

With these scripts, you can implement a fairly sophisticated policy
with regard to who can commit what and where.

If you try to maintain branches using separate repositories, you will
only make life harder for yourself when it comes time to merge, since
you are essentially on your own. The CVS vendor branching mechanism is
woefully inadequate for anything but a model in which some users of a
source code base are maintaining their own local modifications with
respect to a sequence of releases from some source, which is called
the vendor.

Here is how you can try to use CVS vendor branches. Designate the
gamma repository as the official software. Make regular snapshots (via
cvs export) and give it to the wild beta developers. Each time these
developers get a snapshot, they import it into their CVS repository's
vendor branch, and merge down to the trunk, against their local
changes.

Every once in a while, the beta people publish their work, which can
take the form of a cvs rdiff patch between the latest vendor branch
sources and the main trunk. The gamma people validate this and
incorporate it into their codebase---the patch should apply cleanly
because it was produced against their latest code.

When this synchronization happens, the beta people can get an
official, integrated snapshot from the gamma people, and use that to
start a new repository.

This is how CVS is used on a small scale by people who contribute
patches to open source projects. You get the snapshot, import it into
your CVS, work on the trunk, then when you are done get the latest
snapshot, import it, merge it and make a diff. Send the diff to the
maintainers, who can patch cleanly, since you just made it against the
latest sources. The patch goes into the official software and you can
scrap your repository, which serves no purpose any longer.