Peter B. West wrote: > 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.
I'll take your word for how it is used in real life, and this perhaps explains how we got to the status quo. I just wonder "why?" It seems like tagging only the subset of files that need to be different is a much more elegant way to handle the problem. It 1) greatly simplifies the commit process (it really eliminates the "educating committers" problem that Jeremias mentioned), 2) defers branching individual files until they must be branched, 3) provides a moderately easy way of knowing which files are actually different. It requires only that when a file needs to be added to the branch that someone run a "cvs tag" command on that file, and that if you are working on the branch you use "cvs checkout -f" to make sure you get the trunk version of the common files. If you fail to do the latter, the compiler will no doubt remind you. Although I'm pretty green with CVS, I have used RCS pretty heavily, and have used the above concept successfully with it. We used scripts to accomplish the same sort of things that CVS handles so nicely, but the concepts are pretty much the same. Since the success of maintaining any re-merged work depends on this concept, I'll do some testing on that first to make sure that I'm not missing anything. BTW, it is this viewpoint that makes me think that we have the branches reversed. If the working / maintenance code is the core code that you start with, then the new design code is the stuff that is branching off. Go back to the point in time immediately before the first file was changed in the redesign work. You modify file foo.java and want to commit it to the repository as the first piece of the redesign. You have decided that the redesign will live in the trunk and that the old code will be pushed onto a branch (exactly as we have done). The only way that you can accomplish this is to force a checkin of the code that **did not** change onto the branch. Other have pointed out that it really doesn't matter where the branches are, and in a strict sense they are correct (and we can use the admin -b to change the default branch if we want to). However, it seems extremely awkward and counter-intuitive to create a branch on code that didn't change. I don't feel strongly about the position of the two branches. However, there seems to be general agreement that this is a complex project. Since complexities tend to be exponential in nature, every one of them that can be eliminated tends to have a large benefit. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
