On Tue, Apr 6, 2010 at 10:32 AM, Hyrum K. Wright <hyrum_at_hyrumwright.org> 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, stsp_at_apache.org 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!):
---trunk_at_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-improvements_at_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:
---trunk_at_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-improvements_at_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
Received on 2010-04-06 17:56:38 CEST