On Thu, Feb 11, 2010 at 7:44 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Tue, 2010-02-09, Paul Burba wrote:
>> 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 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
Received on 2010-02-11 15:11:39 CET