On Tue, Apr 6, 2010 at 10:32 AM, Hyrum K. Wright <[email protected]> wrote: > I'm interested to know why this is needed. Is our merge tracking > implementation so broken that it doesn't handle these types of things? > > (Forgive me if I'm being naïve here.) > > -Hyrum > > On Apr 6, 2010, at 9:24 AM, [email protected] wrote: > >> Author: stsp >> Date: Tue Apr 6 14:24:27 2010 >> New Revision: 931164 >> >> URL: http://svn.apache.org/viewvc?rev=931164&view=rev >> Log: >> On the svn-patch-improvements branch, block r931162 from trunk to avoid >> a cyclic merge the next time this branch is synced to trunk. >> >> Modified: >> subversion/branches/svn-patch-improvements/ (props changed) >> >> Propchange: subversion/branches/svn-patch-improvements/ >> ------------------------------------------------------------------------------ >> --- svn:mergeinfo (original) >> +++ svn:mergeinfo Tue Apr 6 14:24:27 2010 >> @@ -33,4 +33,4 @@ >> /subversion/branches/tc_url_rev:874351-874483 >> /subversion/branches/tree-conflicts:868291-873154 >> /subversion/branches/tree-conflicts-notify:873926-874008 >> -/subversion/trunk:918519-930647 >> +/subversion/trunk:918519-930647,931162
Merge tracking has always had problems with cyclic (or reflective if your prefer) merges, see http://subversion.tigris.org/issues/show_bug.cgi?id=2837 The svn-patch-improvements branch illustrates the problem; here is what we have (excluding r931164!): ---tr...@918518------------------------------------r931162-------> | | | | ^ | | | | | copy sync merges cherry picked | keeping branch back to trunk | up to date with ^ ^ | trunk through | | | r930647 | | | | | | | | V V V V | | svn-patch-improveme...@918521-----------------r929288--r931140--> What happens when this branch is next synced with trunk? The current merge logic will look at the mergeinfo on the branch and assume it needs to merge ^/subversion/trunk -r930647:HEAD. Problem is, that range includes r931162, which is the cherry pick from the branch. So it will be included in the applied diff. This *might* not be a problem if no further changes have occurred on the branch in the files touched by r929288 and r931140. In fact, in this case they will currently merge cleanly: C:\SVN\src-branch-svn-patch-improvements>svn up -r931163 U . Updated to revision 931163. C:\SVN\src-branch-svn-patch-improvements>svn merge ^^/subversion/trunk . --- Merging r930648 through r931175 into '.': U subversion\libsvn_diff\parse-diff.c U subversion\libsvn_client\mergeinfo.c U subversion\tests\libsvn_subr\dirent_uri-test.c U subversion\tests\libsvn_client\client-test.c U subversion\tests\cmdline\mergeinfo_tests.py U subversion\tests\cmdline\patch_tests.py U tools\buildbot\slaves\win32-SharpSvn\svntest-test.cmd U tools\buildbot\slaves\win32-SharpSvn\svntest-cleanup.cmd U tools\buildbot\slaves\win32-SharpSvn G . But obviously if more work took place on the branch in the files touched by r929288 and r931140, then needless conflicts might occur. Now let's look at the branch with Stefan's --record-only merge applied: ---tr...@918518--------------------------------------r931162-------------------> | | | | ^ |__________ | | | | | | copy sync merges cherry picked --record-only | keeping branch back to trunk merge of r931162 | up to date with ^ ^ | | trunk through | | | | r930647 | | | | | | | | | | V V V V | | V svn-patch-improveme...@918521-----------------r929288--r931140----r931164---> Now if we sync merge the branch with trunk, the mergeinfo on the branch causes two discrete diffs to be applied: ^/subversion/trunk -r930647:931161 ^/subversion/trunk -r931162:HEAD C:\SVN\src-branch-svn-patch-improvements>svn revert -R . -q C:\SVN\src-branch-svn-patch-improvements>svn up U . Updated to revision 931188. C:\SVN\src-branch-svn-patch-improvements>svn merge ^^/subversion/trunk . --- Merging r930648 through r931161 into '.': U subversion\libsvn_client\mergeinfo.c U subversion\tests\libsvn_subr\dirent_uri-test.c U subversion\tests\libsvn_client\client-test.c U subversion\tests\cmdline\mergeinfo_tests.py U subversion\tests\cmdline\patch_tests.py U tools\buildbot\slaves\win32-SharpSvn\svntest-test.cmd U tools\buildbot\slaves\win32-SharpSvn\svntest-cleanup.cmd U tools\buildbot\slaves\win32-SharpSvn --- Merging r931163 through r931190 into '.': U subversion\include\private\svn_mergeinfo_private.h U subversion\libsvn_subr\mergeinfo.c U subversion\tests\libsvn_subr\mergeinfo-test.c Now it is probably tempting to say, "Look at the mergeinfo on trunk created by r931162": C:\SVN\src-branch-svn-patch-improvements>svn diff -N ^^/subversion/trunk -r931161:931162 Property changes on: . ___________________________________________________________________ Modified: svn:mergeinfo Merged /subversion/branches/svn-patch-improvements:r929288,931140 "Can't we deduce from that mergeinfo that we don't need to merge this change back to the svn-patch-improvements branch when we next sync it?" Not really, because we don't know if r931162 included any other changes *besides* the merge from svn-patch-improvements. If it did, do we include or exclude those changes from being merged? ~~~~~ Anyhow, cyclic merges are not handled very well outside of reintegrate. If anybody out there thinks they have a solution for issue #2837, by all means, patches welcome. Paul
