On Mon, Jan 25, 2010 at 9:32 AM, Julian Foad <julian.f...@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....@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....@875961
^/subversion/branches/1.6.x-r891...@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.
I created issue #3564 to track this. I won't have time for at least a
few days to dive into this, but I plan to. In the meantime if anyone
wants to take a look, please have at it. A test to reproduce the
problem would be quite lovely ;-)
Paul
> And is it ever meant to print any merge
> activity ("U STATUS") without first having printed a "--- Merging ..."
> header line?
Definitely not!
Paul
P.S. FWIW, 1.6.9 does the right thing in this case, i.e. nothing:
C:\SVN\src-branch-1.6.x>svn info
Path: .
URL: https://svn.apache.org/repos/asf/subversion/branches/1.6.x
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 902803
Node Kind: directory
Schedule: normal
Last Changed Author: julianfoad
Last Changed Rev: 902204
Last Changed Date: 2010-01-22 13:29:55 -0500 (Fri, 22 Jan 2010)
C:\SVN\src-branch-1.6.x>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
C:\SVN\src-branch-1.6.x>svn merge ^^/subversion/branches/1.6.x-r891672/@902803
C:\SVN\src-branch-1.6.x>
