"Paul D. Smith" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > This is good, and a long way better than base CVS, but it's still > not really what ClearCase is capable of. > > ClearCase creates an entirely new piece of metadata for every merge in > each element recording the from/to versions. That means that in > ClearCase you can merge individual elements alone onto multiple > branches, you don't have to merge the entire branch at once. > > Also, ClearCase's merge algorithm actually takes into account the entire > history of the element plus merge metadata, while Meta-CVS doesn't. > This won't matter for simple merges where Meta-CVS provides the proper > baseline, but it matters a great deal for complex merges which span > multiple branches. For example if you have a branch A, B, and C: you > merge from A to C, then later you merge from A to B. Then you want to > merge from B to C--ClearCase will realize that for some elements it can > use a more recent base version because of the previous merge of A to C.
Some time ago I spent a while racking my brains about problems like this; and I came up with some solutions that will probably turn into post 1.0 features, if anything. One thing I can do in Meta-CVS is record the ancestry of a branch. So that if you make branch A from the trunk, and then branch B from A, I can record the fact that A is the ``parent'' of B, and the main trunk is the parent of A. Now this can help in merges if someone wants to go from B directly down to the main trunk. We can perhaps see to what extent B has already been merged to the intermediate A, and how much of A has already gone down to the trunk. At the very least, it's necessary to handle the branchpoint problem: the first merge of B to the main trunk has to include all of the A history from the A branchpoint to the B branchpoint; it can't just start at the B branchpoint. Meta-CVS does not do this right; if you merge from branch B, that means from the start of branch B. Is this truly wrong? What if B is a feature that is independent of what happened on branch A already? Hmm. The case can be made for having it either way: merge only the B part, or merge the A ancestry as well. It's clear that if you allow a lot of free branching in any direction you end up with repeated merges. Version control systems which are designed to support ``product branches'' from the start can incorporate algorithms to deal with that. In CVS we are kind of stuck with the model of ``merge back to your immediate parent''. > I'm not trying to put down Meta-CVS in any way: I think it's a great Your criticism is perfectly rational and correct, which is all that matters. Now if you want to see my response to some irrational criticism, for your amusement, take a look at: users.footprints.net/~kaz/mcvs-criticisms.html :) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs