[cvsnt] Mergepoint issues on 220.127.116.11 b2382
a.krey at gmx.de
Fri Jan 12 17:04:52 GMT 2007
On Fri, 12 Jan 2007 16:22:18 +0000, Tony Hoyle wrote:
> Andreas Krey wrote:
> > This is not what the patch does, obviously. It chooses the diff from
> > 1.2 to 18.104.22.168 to be merged into the head. You need to used the base
> > of the last merge arrow as the base version for the merge, not the tip.
> But 1.2 is *not* an ancestor of 22.214.171.124,
It has become one by inserting the merge arrow. 126.96.36.199 contains
the changes made in 1.2 as well as the head, so it is effectively
the ancestor. Merge arrows are no thinner than the other lines
in the revision graph. You need to follow both to find out into
which revisions the change of a given revision has been propagated.
> so the merge is bogus.
But it happens to yield the correct result. And that is not a
coincidence. Effectively, by the merge into the branch, you are
pruning away the path via 188.8.131.52 and 184.108.40.206 and leaving 1.2
as the new common ancestor.
> All you've done is degraded merge into a simple copy.
That is only because I did not modify the head before the backmerge.
If I did, that would have been a regular merge with possibility
> In a true merging
> situation the two branches can easily follow independent paths and never
> be identical to each other - mergepoints are designed to help you
> extract the difference between two points on the *same* branch.
Nope. They are designed to avoid the manual bookkeeping necessary
with plain cvs. Says so on the aforementioned cvsnt wiki page.
> What you seem to want is not mergepoints but a copy operation.
Nope. Even when the backmerge degrades into a copy because nobody
else worked the head in between, the recorded merge arrow allows
to continue working in the same branch. If I would copy around
cvs (and not leave the merge arrow) the next merge into the
branch would go bad as well.
More information about the cvsnt