Enabling symmetric merge, and UI details
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 3 Aug 2012 20:25:58 +0100 (BST)
Hi, merge fans.
It's time to lose the temporary '--symmetric' option and make it the default mode in 'svn'.
Some people have been kind enough to try using the 'symmetric' mode and report back, mainly Paul to whom I am most grateful. I am aware of two current issues (,) which I am investigating and they are looking simple enough to be resolved soon. Please help me flag up any other issues.
Before we consider the details of the UI changes, I thought back to how the user base would see 'symmetric merge' in the context of the history of Subversion's merge tracking, and wrote a brief overview at
I think, and please tell me if you disagree, that we will make the best progression with a UI like this, which the attached patch  roughly implements for illustration:
* Use the 'symmetric'/'auto' mode for any merge that was previously a reintegrate or a non-reintegrate 'sync' merge. That is, when there is:
- just one source;
- no start revision;
- (an end revision may be specified, which can be done without a start rev by specifying peg-rev syntax: SOURCE@END_REV);
- no incompatible options (such as --ignore-ancestry).
* If the code chooses a reintegrate-like merge, it will apply the strict WC checks like reintegrate does in 1.7.
* Make the '--reintegrate' option mean the user believes a reintegrate-style merge is needed, so check that the previous merge is as expected (that it, in the opposite direction) and bail out if not.
* Mark the '--reintegrate' option as deprecated, as the reason for its existence has gone.
* Delete the '--symmetric' option; it was only there for testing and has not been released.
WHAT WILL NOT CHANGE
Two specific things to call out:
* A merge specifying '--reintegrate' merge will not change in any scenario where 'merge --reintegrate' is the user's best option today.
* A merge specifying '-r X:Y' will not change. This requests a cherry-pick merge, using merge tracking to avoid re-merging any revs in the range that are already merged. Currently, if 'X' is 1 or a low enough number such that there are no unmerged revisions before 'X', then Subversion performs exactly the same kind of merge as when 'X' is not specified, which we call a 'sync' merge. I believe we could make a later enhancement to automatically use 'reintegrate' mode if that would be the correct thing to do for merging the requested range.
OPTIONS NOT ALLOWED WITH --REINTEGRATE
The following options are not allowed with '--reintegrate' in 1.7 but are allowed for non-reintegrate merge-tracking merges:
My recommendation for these options is that if we choose a reintegrate-style merge then we error out, saying "the required merge is reintegrate-like, and option --X is not supported for this kind of merge". Otherwise we handle the option just like in 1.7.
Please let me know if this seems good, while I go and adjust the help text.
 Unexpected revision number in the "Merging r6 through r9" notification, <http://svn.haxx.se/dev/archive-2012-08/0005.shtml>.
 Behaviour when the root has not been merged, a subtree has, and now we merge the root in the other direction, <http://svn.haxx.se/dev/archive-2012-08/0008.shtml>.
 Every time I say 'symmetric', I try to think of a better name. It's not symmetric, it's just based on a symmetric model. 'automatic'? 'bidirectional'?
 Need to choose terminology for a reintegrate-style merge, for the UI. "reversing direction"?
 Wiki page, <http://wiki.apache.org/subversion/SymmetricMerge>.
 Attachment, 'enable-symmetric-merge-1.patch'.
 GUIs and other clients can switch to the new svn_client API when
they are ready to do so; here I'm just talking about our 'svn' client.
Subversion Live 2012 - 2 Days: training, networking, demos & more! http://bit.ly/NgUaRi
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
This is an archived mail posted to the Subversion Dev mailing list.