On Tue, Jan 26, 2010 at 6:01 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, Jan 25, 2010 at 12:45 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Mon, Jan 25, 2010 at 9:32 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
>>> After merging all changes from a branch into the WC, a second attempt of
>>> the same merge brings in a different file.
>>>
>>> Full Details
>>>
>>> I tried a merge in a clean WC of the branch 1.6.x_at_902803, using an
>>> r902780M trunk build of svn. (I confirmed with an r902508 trunk build
>>> that excludes the recent patch to add notifications when mergeinfo is
>>> being recorded. The results are the same except lacking the extra
>>> notifications.)
>>>
>>> [[[
>>> $ svn merge --dry-run ^/subversion/branches/1.6.x-r891672/@902803
>>> --- Merging r891676 through r902803 into '.':
>>> U subversion/tests/cmdline/externals_tests.py
>>> U subversion/libsvn_client/commit_util.c
>>>
>>> $ svn merge ^/subversion/branches/1.6.x-r891672/@902803
>>> --- Merging r891676 through r902803 into '.':
>>> U subversion/tests/cmdline/externals_tests.py
>>> U subversion/libsvn_client/commit_util.c
>>> --- Recording mergeinfo for merge of r891676 through r902803 into '.':
>>> U .
>>>
>>> $ svn diff -N
>>>
>>> Property changes on: .
>>> ___________________________________________________________________
>>> Modified: svn:mergeinfo
>>> Merged /subversion/branches/1.6.x-r891672:r891677-902803
>>> ]]]
>>>
>>> So far, so good.
>>>
>>> Then I requested the same merge again in the same (now modified) WC,
>>> expecting nothing further should happen, but I got:
>>>
>>> [[[
>>> $ svn merge --dry-run ^/subversion/branches/1.6.x-r891672/@902803
>>> U STATUS
>>>
>>> $ svn merge ^/subversion/branches/1.6.x-r891672/@902803
>>> U STATUS
>>> --- Recording mergeinfo for merge of r891676 through r902803 into '.':
>>> G .
>>>
>>> $ svn diff -N
>>>
>>> Property changes on: .
>>> ___________________________________________________________________
>>> Modified: svn:mergeinfo
>>> Merged /subversion/branches/1.6.x-r891672:r891677-902803
>>> Index: STATUS
>>> ===================================================================
>>> --- STATUS (revision 902803)
>>> +++ STATUS (working copy)
>>> @@ -114,15 +114,6 @@
>>> Votes:
>>> +1: stsp, rhuijben
>>>
>>> - * r892050, 892085
>>> - Fix a reintegrate bug which can occur when the merge source has mergeinfo
>>> - that explicitly describes common history with the reintegrate target.
>>> - Justification:
>>> - Reintegrate merges may not work if the reintegrate source has self-
>>> - referential mergeinfo that is also self-referential to the reintegrate
>>> - target. This occured in our own repository, see
>>> - http://svn.haxx.se/dev/archive-2009-12/0338.shtml.
>>> - Votes:
>>> +1: pburba, rhuijben
>>>
>>> * r891672
>>> @@ -185,8 +176,6 @@
>>> Justification:
>>> APIs should do what they say they do.
>>> Votes:
>>> - +1: pburba
>>> -
>>> Veto-blocked changes:
>>> =====================
>>>
>>> ]]]
>>>
>>> Why is it merging STATUS now?
>>
>> Why indeed. I see similar problems with STATUS, though I actually get
>> a conflict.
>>
>> C:\SVN\src-branch-1.6.x-2>svn merge ^^/subversion/branches/1.6.x-r891672/@902803
>> --- Merging r891676 through r902803 into '.':
>> U subversion\tests\cmdline\externals_tests.py
>> U subversion\libsvn_client\commit_util.c
>> --- Recording mergeinfo for merge of r891676 through r902803 into '.':
>> U .
>>
>> C:\SVN\src-branch-1.6.x-2>svn merge ^^/subversion/branches/1.6.x-r891672/@902803
>> Conflict discovered in 'C:/SVN/src-branch-1.6.x-2/STATUS'.
>> Select: (p) postpone, (df) diff-full, (e) edit,
>> (mc) mine-conflict, (tc) theirs-conflict,
>> (s) show all options: p
>> C STATUS
>> G subversion\tests\cmdline\externals_tests.py
>> G subversion\libsvn_client\commit_util.c
>> --- Recording mergeinfo for merge of r891676 through r902803 into '.':
>> G .
>> Summary of conflicts:
>> Text conflicts: 1
>>
>> C:\SVN\src-branch-1.6.x-2>
>>
>> Doing a quick debug I saw that we are call
>> merge.c:drive_merge_report_editor() in an inexplicable attempt to
>> merge this diff...
>>
>> ^/subversion/branches/1.6.x_at_875961
>> ^/subversion/branches/1.6.x-r891672_at_892189
>>
>> ...Which prompted some cursing on my part.
>>
>> I'm not entirely sure what is wrong here, though I suspect part of the
>> cause is that r892189 was a merge from trunk to the
>> ^/subversion/branches/1.6.x-r891672 branch in which no mergeinfo
>> changes were committed -- see
>> http://svn.haxx.se/dev/archive-2010-01/0615.shtml.
>
> A quick update. I redid the merge of r892189 so the correct mergeinfo
> was created (still no idea how this didn't happen the first time
> around, but that investigation continues). Unfortunately the repeat
> merge still incorrectly attempts to repeat the merge, despite the
> local mergeinfo changes showing it has already been done, and results
> in the odd conflict on STATUS.
>
> C:\SVN\src-branch-1.6.x-2>svn merge ^^/subversion/branches/1.6.x-r891672
> Conflict discovered in 'C:/SVN/src-branch-1.6.x-2/STATUS'.
> Select: (p) postpone, (df) diff-full, (e) edit,
> (mc) mine-conflict, (tc) theirs-conflict,
> (s) show all options: p
> C STATUS
> G subversion\tests\cmdline\externals_tests.py
> G subversion\libsvn_client\commit_util.c
> --- Recording mergeinfo for merge of r891676 through r903475 into '.':
> G .
> Summary of conflicts:
> Text conflicts: 1
>
> C:\SVN\src-branch-1.6.x-2>
>
> continuing to look into this...
Hi Julian,
Sorry for the delay, had been working on some other things. I fixed
this in r908335
http://svn.apache.org/viewvc?view=revision&revision=908335.
Paul
Received on 2010-02-10 04:10:51 CET