[cvsnt] Mergepoint issues on 2.5.0.3 b2382

Andreas Krey a.krey at gmx.de
Fri Jan 12 20:14:59 GMT 2007


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


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook