Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "SvnMergeTheory" page has been changed by JulianFoad: http://wiki.apache.org/subversion/SvnMergeTheory?action=diff&rev1=44&rev2=45 This is all very well, and merges the right set of logical changes, but the first phase is not as good as it could be. Changes A2 and A3 have already been merged with the early part of branch B (up to B3) and the result committed as A4; that means the user has already done any necessary conflict resolution for that part of the merge. By merging the same physical changes A2 and A3 again into B, we require the user to resolve the same conflicts again for this part of the merge, as well as solving any further conflicts related to merging change A5. (Of course in any given particular merge it is possible that there might be no conflicts, or no conflicts that aren't resolved automatically at the text level by the 3-way merge tool, but I'm talking about the general case.) - What should happen instead? It would be better to choose the younger common ancestor B3 rather than A1 as the base of the merge, and therefore merge the change B3:A4 instead of A1:A3, because then any conflict resolution associated with merging A:2-3 with B:2-3 has already been done (in A4) and we'd only be concerned with merging the newer changes on A (B3:A4, A4:A5) with the newer changes on B (B3:B5). See [[#Unifying_Sync_and_Reintegrate|Unifying_Sync_and_Reintegrate]], below. + What should happen instead? It would be better to choose the younger common ancestor B3 rather than A1 as the base of the merge, and therefore merge the change B3:A4 instead of A1:A3, because then any conflict resolution associated with merging A:2-3 with B:2-3 has already been done (in A4) and we'd only be concerned with merging the newer changes on A (B3:A4, A4:A5) with the newer changes on B (B3:B5). See [[#Unifying_Sync_and_Reintegrate|Unifying Sync and Reintegrate]], below. Up until this point I was working on trying to make Subversion automatically skip an old reintegrate in the same way that the keep-alive dance (record-only merge) would skip it, but now we can see that the keep-alive dance is simply wrong: it is worse than deleting the branch and creating it again. So I'll turn my attention to calculating the proper merge. @@ -185, +185 @@ The conclusion is: to merge correctly, the 3-way merge base should be chosen on 'this' or 'that' branch according to the direction of the last merge, not according to whether the ''current'' merge is a reintegrate or a sync. - == The Unified Algorithm == + We call the result a ''symmetric merge'' algorithm. + + == The Symmetric Merge Algorithm == Today we have ''sync'' which looks for a base on the source branch, and ''reintegrate'' which looks for a base on the target branch. What we need is a single algorithm that finds the most recent base, on either branch. Like the current ''reintegrate'', it needs to choose a base for the 3-way merge, and potentially a different base (this one always on the source branch) for the mergeinfo to be recorded. Considering the final merge in the "sync after reintegrate" graph above, we have: @@ -201, +203 @@ [TODO] Express it as an algorithm. - == The Unified Algorithm with Cherry-Picks == + == Symmetric Merge with Cherry-Picks == - Next, we need to account for cherry-picks. If there are cherr-picks from the source [...], we look for the end of the first gap. [TODO...] + Next, we need to account for cherry-picks. If there are cherry-picks from the source [...], we look for the end of the first gap. [TODO...] ---- = Appendices =
