You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2010/02/10 03:10:10 UTC
Re: svn merge - repeat merge is not a no-op
On Tue, Jan 26, 2010 at 6:01 PM, Paul Burba <pt...@gmail.com> wrote:
> On Mon, Jan 25, 2010 at 12:45 PM, Paul Burba <pt...@gmail.com> wrote:
>> On Mon, Jan 25, 2010 at 9:32 AM, Julian Foad <ju...@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@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@875961
>> ^/subversion/branches/1.6.x-r891672@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
Re: svn merge - repeat merge is not a no-op
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Feb 11, 2010 at 7:44 AM, Julian Foad <ju...@wandisco.com> wrote:
> On Tue, 2010-02-09, Paul Burba wrote:
>> On Tue, Jan 26, 2010 at 6:01 PM, Paul Burba <pt...@gmail.com> wrote:
>> > On Mon, Jan 25, 2010 at 12:45 PM, Paul Burba <pt...@gmail.com> wrote:
>> >> On Mon, Jan 25, 2010 at 9:32 AM, Julian Foad <ju...@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@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 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 .
> [...]
>
>> 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.
>
> Thanks, Paul. I re-tested and this looks good now.
>
> [[[
> $ 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 merge --dry-run ^/subversion/branches/1.6.x-r891672/@902803
>
> $ svn merge ^/subversion/branches/1.6.x-r891672/@902803
> --- Recording mergeinfo for merge of r891676 through r902803 into '.':
> G .
> ]]]
>
> There's just a little visual oddity of that "Recording mergeinfo ...
> G ." output, but that seems to mean "recording if necessary" so that's
> fine. I confirmed that the mergeinfo did not change in that second
> merge.
Yeah, despite the improvements in 1.7 to prevent mergeinfo from being
recorded on subtrees unaffected by the merge, merge still always
records mergeinfo on the target itself. However, there is no logic to
check that what is being set is not the same as what is already there.
Paul
Re: svn merge - repeat merge is not a no-op
Posted by Julian Foad <ju...@wandisco.com>.
On Tue, 2010-02-09, Paul Burba wrote:
> On Tue, Jan 26, 2010 at 6:01 PM, Paul Burba <pt...@gmail.com> wrote:
> > On Mon, Jan 25, 2010 at 12:45 PM, Paul Burba <pt...@gmail.com> wrote:
> >> On Mon, Jan 25, 2010 at 9:32 AM, Julian Foad <ju...@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@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 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 .
[...]
> 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.
Thanks, Paul. I re-tested and this looks good now.
[[[
$ 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 merge --dry-run ^/subversion/branches/1.6.x-r891672/@902803
$ svn merge ^/subversion/branches/1.6.x-r891672/@902803
--- Recording mergeinfo for merge of r891676 through r902803 into '.':
G .
]]]
There's just a little visual oddity of that "Recording mergeinfo ...
G ." output, but that seems to mean "recording if necessary" so that's
fine. I confirmed that the mergeinfo did not change in that second
merge.
- Julian