Re some recent questions on this topic. As I understand it, creating a branch in the tree off an existing file set simply involves tagging the set of files with the new branch tag. From that point on, as long as a particular file remains unchanged, a checkout on either branch will retrieve a identical *revision* of the file. As soon as a change is made to a file in either branch, the retrieved files will differ by that delta, and the unchanged file will retain the original revision number.

Maintaining common code across different branches is another question. Here's an approach which *may* work. Interested parties might like to create a dummy CVS tree and try it.

As well as the two full development branches, create a branch (or branches) specifically for common code sets. From that branch, cvs remove all of the non-common files. Proceed with parallel development. When one wants to make changes to the common code, notify everyone of the intention. Negotiate any conflicts of intention. (This may be a good reason to split the common code into a number of modules, each with its own reference branch.)

Make the changes, test and perform a normal commit. Now merge from your branch into the common code branch or branches. This is the tricky part. CVS may spit the dummy here, but I hope not. I hope that it will simply report on all of the unknown files that you are throwing its way, while going ahead with a merge of the files it knows about.

Tag your branch and tag the common branch according to some agreed scheme. Notify completion. Now someone working on another branch or branches can merge from the common branch into his branch. He then tags his branch according to the same scheme. Note that future merges to and fro will be relative to these tag points.

It's kinda messy, but it might just be feasible.

"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to