Matt L <[EMAIL PROTECTED]> wrote in message news:<m3GH9.11592$dz2.1609816@stones>... > 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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
