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. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
