Re: Symmetric merge -- current test failures when enabled
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 10 May 2012 08:36:22 +0100 (BST)
Branko Čibej wrote:
Well, I was hand-waving a bit, meaning to dismiss this as some kind of simple side-issue, which I think it is. I agree that, in principle, there need not be any other kind of merge. In practice, however, we might want to bypass the part of the algorithm that traverses the merge graph and branching history to find an appropriate base, if we have a degenerate case where we know in advance what base to use, and if the source and target branches do not both exist as separate branches in the repository.
In this case, the merge base is always the youngest common ancestor (YCA) which is the WC pristine version. The target branch consists only of the YCA followed by the WC working version; there is no commit on the target branch, not even a branch-creation commit, so it is a somewhat degenerate case of a 'branch'.
rev 1 2 [o = a repository node]
Nevertheless, I agree with you that it's best if the algorithm can handle such cases. It's not all *that* special.
Looking more closely at these test failures, the (initial) problem is just a difference between expecting the merge notification to say "Merging r2" when it actually says "Merging differences between repository URLs", and that is caused by the symmetric-merge code failing to find a base on the source branch. I suspect (but haven't delved deeper yet) that I can adjust the find-a-base code to report revision 1 as the base-on-source  in this case, and thus these merges yield the previously expected notification and results.
 And I will change the code to prefer a base-on-source over a base-on-target when they are the same location. At the moment, the subsequent code path depends explicitly on whether we chose a base-on-source or a base-on-target, and gives a different notification, although in theory (and, I hope, later in practice) the same code path should handle either way.
This is an archived mail posted to the Subversion Dev mailing list.