Victor Mote wrote:
Peter B. West wrote:

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.

The first part of this is correct, I think. If you have 100 files, and 30 of
them need to be branched, those 30 files are tagged with a branch ID. To get
a complete set of code on that branch, I think you would have to use
checkout -f, so that your CVS client knows how to find the other 70 files on
the default branch. I am almost sure that if changes are made to any of
those 70 files, they will be seen in this scheme by both those working on
the trunk and those working on the branch. This is where we wish we were
right now, but I think what happened is that basically **all** of the files
got tagged with a branch ID, effectively forking a bunch of them that would
have been better to leave unified. It may be possible to restore this state
even now. More on this in my response to Jeremias to follow.

Branches generally don't occur with subset of files. The usual procedure is to tag a working set of files, then checkout the tag. If there are files you don't want in the new working set, delete and 'cvs remove' them. Until you 'cvs remove', the comments I made above would apply, I think. That's the way I would envisage a new subset branch being created. But see Jeremias' comments on the difficulties of educating committers.

"Lord, to whom shall we go?"

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

Reply via email to