(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)
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.
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:
>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.
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).
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
3) Some as of yet undiscovered bug
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
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
Received on 2013-02-27 22:22:22 CET