Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Fri, 12 Jan 2007 10:34:19 +0000, Michael Wojcik wrote: ... > No, Tony's right. There's no guarantee that "1.1.2.3 contains the > changes made in 1.2"; in particular, CVSNT can't guarantee that. > 1.1.2.3 will only contain all the changes from 1.2 if the person > performing the merge resolves conflicts in a lossless fashion, and > doesn't otherwise modify the results of the merge. That is the only case that warrants a merge arrow (see response to Tony). :-) > That's not guaranteed; in fact, it's not even desirable in all cases. > Consider the case where ongoing development in the trunk has included > both fixes and substantial new features. Now perhaps the fixes need to > be merged into the branch, but the new features should not be, or even > cannot be (eg due to external dependencies). But in that case I would argue that the process is broken -- fixes and features need to be separated when they are needed separately. This isn't easy either. Unfortunately, for parts of the file(s) 1.2 *is* the base, and for parts it isn't. Some part of the following merges is always bogus. ... > That metaphor isn't meaningful. 1.2 is not an ancestor of 1.1.2.3. > That's all there is to it. CVSNT knows that real common ancestors > really are common; it can't assume that for any other revisions. Actually it can't in regular revisions either; I may just as well have thrown out a feature directly after doing the branch. This should not be merged back into the head either. Both cases are effectively cheating on cvs. ... > Perhaps what we need is another option to update, used in place of -j, > which says "if there's a mergepoint from the destination branch to the > source branch, then act as if the tail of that mergepoint was the > closest common ancestor". This is an interesting point: The mergepoint-aware -j hijacks another meaning of (one) -j. One could argue that mergepoint-aware merges should be done differently in the first place (and that only those leave a new merge arrow). > cvs update -Jtmp-ak-test-br t4.txt That version could later be extended to look at the full revision web for getting the proper merge ancestor. Way later... I've seen (clear)cases where one feature branch was merged into the next two features before ever hitting the head. Andreas -- np: 4'33