On Wed, Feb 27, 2013 at 10:21 PM, Paul Burba <ptbu...@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 <markp...@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.fuhrm...@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 <markp...@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@1414755------------@1442089---@r1445080------------> > | | | ^ > copy sync sync | > | merge merge conflict-filled > | | | automatic > | | | merge > | | | | > V V V | > fsfs-format7@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 *
