Victor Mote wrote:
Victor,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.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
