On Wed, Feb 27, 2013 at 10:21 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> (Stefan - If you don't have time to read all this please at least take
> a look at the short questions at the very end)
>
No worries :) Thanks for digging into this problem.
General remark: I'm working at and committing from my
Ubuntu 12.04 laptop since mid January and will continue
to do so until Easter. That means: Subversion 1.6.17.
> On Mon, Feb 18, 2013 at 11:54 AM, Mark Phippard <markphip_at_gmail.com>
> wrote:
>
> > BTW, how are you managing your branch? I tried merging it back to
> > trunk to get an idea on the diff and there were a lot of text and tree
> > conflicts. I thought I had seen you doing synch merges from trunk in
> > the past so I assumed it would merge back.
>
> On Thu, Feb 21, 2013 at 5:05 AM, Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com> wrote:
>
> > Hm. I split fsfs.c and .h into multiple files on the
> > branch and the first merge from /trunk required
> > significant manual intervention. Since that, merges
> > have been clean because fsfs.* wasn't touched
> > on /trunk.
> >
> > If I understand Julian's merge changes in 1.8,
> > reintegrating should work because there has been
> > no cherry picking etc.
>
> On Thu, Feb 21, 2013 at 11:04 AM, Mark Phippard <markphip_at_gmail.com>
> wrote:
>
> > I see this when using 1.8:
> >
> > $ svn mergeinfo ^/subversion/branches/fsfs-format7
> > youngest common ancestor
> > | last full merge
> > | | tip of branch
> > | | | repository path
> >
> > 1414755 1448697
> > | |
> > --| |------------ subversion/branches/fsfs-format7
> > /
> > /
> > -------| |------------ subversion/trunk
> > |
> > 1447423
> >
> > It seems to imply that it does not think you have ever synched with
> > trunk. So maybe it is trying to replay every revision from your
> > branch when I merge back and that is why it gets so many conflicts?
>
> I found the cause of the conflict filled reintegrate merge. The
> automatic merge code seems to be doing the right thing re Mark's
> automatic merge above, the problem arises earlier.
>
> First, here is the relationship between the two branches in question:
>
> trunk_at_1414755------------@1442089---_at_r1445080------------>
> | | | ^
> copy sync sync |
> | merge merge conflict-filled
> | | | automatic
> | | | merge
> | | | |
> V V V |
> fsfs-format7_at_1414757---r1442344---r1445479------------>
>
> The first problem is that the "sync" merge in r1442344 recorded the
> wrong mergeinfo:
>
> >svn log ^^/subversion/branches/fsfs-format7 -r1442344
> ------------------------------------------------------------------------
> r1442344 | stefan2 | 2013-02-04 15:48:05 -0500 (Mon, 04 Feb 2013) | 2 lines
>
> On the fsfs-format7: ketchup merge from /trunk up to and including
> r1442089.
> Some conflicts due to splitting up fs_fs.c needed to be resolved.
> ------------------------------------------------------------------------
>
> >svn diff --depth empty ^^/subversion/branches/fsfs-format7 -c1442344
> Index: .
> ===================================================================
> --- . (revision 1442343)
> +++ . (revision 1442344)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:ignore
> ## -49,3 +49,6 ##
> zlib
> sqlite-amalgamation
> serf
> +gtest
> +.git
> +.gitignore
> Modified: svn:mergeinfo
> Merged /subversion/branches/issue-4116-dev:r1424719-1425040
> Merged /subversion/trunk:r1414758-1442089
> ^^^^^^^
> Why not r1414756?
> That is the first revision on trunk after
> the branch was created.
>
I simply didn't notice it, so I wrongly assumed at the
branch was created from 1414756. Don't remember
which tool I used to created the repo-repo copy to
open the branch.
Merged
> /subversion/branches/tweak-build-take-two:r1424288-1425049,1425051-1425613
> Merged /subversion/branches/in-repo-authz:r1414342-1424779
> Merged /subversion/branches/issue-4194-dev:r1410507-1414880
> Merged /subversion/branches/wc-collate-path:r1407642
>
> The mergeinfo recorded makes it look like a big cherrypick of
> r1414758-1442089 was done from ^/subversion/trunk to
> ^/subversion/branches/fsfs-format7, rather than a proper sync merge.
> Well, not to worry, the subsequent sync merge committed in r1445479
> will notice that /subversion/trunk:r1414756-1414757 has *not* been
> merged and merge those missing revisions -- they are inoperative but
> that doesn't matter, the mergeinfo should still be recorded. Except
> that didn't happen either:
>
That is no surprise as I merged (lastmerge+1):headRev.
>svn diff --depth empty ^^/subversion/branches/fsfs-format7 -c1445479
> Index: .
> ===================================================================
> --- . (revision 1445478)
> +++ . (revision 1445479)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /subversion/trunk:r1442090-1445080
>
> So why is this a problem? Because later, when we try to merge the
> branch back to trunk, the automatic merge code is trying to determine
> if it is dealing with a "sync" or "reintegrate" style merge, it sees
> that there is a gap in the mergeinfo on the source branch (i.e.
> /subversion/trunk:r1414756-1414757) that makes it appear that the
> branch is *not* fully in sync with the trunk. Not-in-sync means no
> reintegrate-style merge, but rather a normal sync style merge, which
> (just like 1.7 if the --reintegrate option isn't used) doesn't do what
> we want. It tries to merge all of the branches changes, resulting in
> dozens of tree conflicts.
>
Why doesn't the merge code recognize r1414756 as inconsequential?
So that is the cause of the problem Mark observed, but why did the
> sync merges Stefan performed in r1442344 and 1445479 do the wrong
> thing? Repeating those two offending merges I am not able to
> replicate the faulty mergeinfo in either case:
>
> The first sync merge done in r1442344:
>
> C:\SVN\src-branch-fsfs-format7>svn info
> Path: .
> Working Copy Root Path: C:\SVN\src-branch-fsfs-format7
> URL: https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7
> Relative URL: ^/subversion/branches/fsfs-format7
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1442343
> Node Kind: directory
> Schedule: normal
> Last Changed Author: stefan2
> Last Changed Rev: 1442081
> Last Changed Date: 2013-02-04 06:27:56 -0500 (Mon, 04 Feb 2013)
>
> C:\SVN\src-branch-fsfs-format7>svn st
>
> C:\SVN\src-branch-fsfs-format7>svn merge ^^/subversion/trunk . --accept
> postpone
> --- Merging r1414756 through r1450917 into '.':
> U get-deps.sh
> U Makefile.in
> U build.conf
> .
> <SNIP>
> .
> U autogen.sh
> U aclocal.m4
> D packages
> U .
> --- Recording mergeinfo for merge of r1414756 through r1450917 into '.':
> G .
> Summary of conflicts:
> Text conflicts: 5
> Tree conflicts: 1
>
> C:\SVN\src-branch-fsfs-format7>svn diff --depth empty
> Index: .
> ===================================================================
> --- . (revision 1442343)
> +++ . (working copy)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /subversion/branches/issue-4116-dev:r1424719-1425040
> Merged /subversion/trunk:r1414756-1450917
> ^^^^^^^
> That's right! The mergeinfo picks up right
> after the yca.
> Merged
> /subversion/branches/tweak-build-take-two:r1424288-1425049,1425051-1425613
> Merged /subversion/branches/in-repo-authz:r1414342-1424779
> Merged /subversion/branches/issue-4194-dev:r1410507-1414880
> Merged /subversion/branches/wc-collate-path:r1407642
> Modified: svn:ignore
> ## -49,3 +49,6 ##
> zlib
> sqlite-amalgamation
> serf
> +gtest
> +.git
> +.gitignore
>
>
> The second merge in r1445479, which should have filled in the
> mergeinfo gap, also works when I tried it:
>
> C:\SVN\src-branch-fsfs-format7>svn info
> Path: .
> Working Copy Root Path: C:\SVN\src-branch-fsfs-format7
> URL: https://svn.apache.org/repos/asf/subversion/branches/fsfs-format7
> Relative URL: ^/subversion/branches/fsfs-format7
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1445478
> Node Kind: directory
> Schedule: normal
> Last Changed Author: stefan2
> Last Changed Rev: 1445080
> Last Changed Date: 2013-02-12 05:02:13 -0500 (Tue, 12 Feb 2013)
>
>
> C:\SVN\src-branch-fsfs-format7>svn st
>
> C:\SVN\src-branch-fsfs-format7>svn merge ^^/subversion/trunk --accept
> postpone
> --- Merging r1442090 through r1450954 into '.':
> U get-deps.sh
> U Makefile.in
> U build.conf
> .
> <SNIP>
> .
> U INSTALL
> U CHANGES
> D packages
> --- Recording mergeinfo for merge of r1414756 through r1450954 into '.':
> U .
> Summary of conflicts:
> Text conflicts: 1
>
> C:\SVN\src-branch-fsfs-format7>svn diff --depth empty
> Index: .
> ===================================================================
> --- . (revision 1445478)
> +++ . (working copy)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /subversion/trunk:r1414756-1414757,1442090-1450954
> ^^^^^^^^^^^^^^^
> The gap is plugged!
>
> So what happened? There are a few options that I can see:
>
> 1) Transient mergeinfo recording bug that afflicted the client that
> Stefan used to do the merges (I don't recall anything like this
> recently and this is pretty basic stuff that has been in place since
> 1.6).
>
Used 1.6.17. But that does not seem to be the root cause:
$ /usr/bin/svn merge ^/subversion/trunk .
--- Merging r1445081 through r1450992 into '.':
^^^^
So, it recognizes that r1414756 as inconsequential.
U get-deps.sh
... gazillion changes and a conflict on fs_fs.c ...
$ /usr/bin/svn pl -v | grep "trunk"
/subversion/trunk:1414756-1450992
The mergeinfo now covers r1414756 as well.
2) Stefan didn't actually do a sync merge, but rather did a cherry
> pick, e.g. 'svn merge ^/subversion/trunk branch-wc -r1414757:HEAD'.
> Stefan - do you recall how you did these merges? How about what
> client version you used? Did you use --allow-mixed-revisions by
> chance
>
The client that I used will always send revision ranges
to the SVN libs and that is the trigger of what we are
seeing here. So, yes, technically, a cherry pick as in
"picking all cherries that there are".
I guess the question is why we make that a user problem.
The user (me) intended to merge all changes from /trunk
to the branch and told svn where to find these. The fact
that SVN gets confused by completely unrelated changes
not being listed explicitly is a tool (SVN) problem.
3) Some as of yet undiscovered bug
>
Only a usability issue.
> P.S. Stefan, In the meantime I suggest you do the following record
> only merge to plug the gap, so when your branch is ultimately merged
> back to trunk it will be possible via a simple automatic merge:
>
> svn merge ^/subversion/trunk --record-only -r1414755:1414757
>
Done in r1451004.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Received on 2013-02-27 23:27:58 CET