[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn merge - repeat merge is not a no-op

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 9 Feb 2010 22:10:10 -0500

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

This is an archived mail posted to the Subversion Dev mailing list.