[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: Mon, 25 Jan 2010 12:45:19 -0500

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.

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>
Received on 2010-01-25 18:45:56 CET

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