Mark Phippard wrote: > On Thu, Feb 21, 2013 at 5:05 AM, Stefan Fuhrmann > <stefan.fuhrm...@wandisco.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. >> >> >> 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. > > 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?
That graph is wrong or at least misleading. There have been catch-up merges, for example this one: svn log -r1445479 ------------------------------------------------------------------------ r1445479 | stefan2 | 2013-02-13 01:37:54 -0500 (Wed, 13 Feb 2013) | 2 lines On the fsfs-format7: ketchup merge from /trunk up to and including r1445080. No conflicts to revolve. ------------------------------------------------------------------------ $ svn diff --depth=empty -c1445479 ^/subversion/branches/fsfs-format7 Index: . =================================================================== --- . (revision 1445478) +++ . (revision 1445479) Property changes on: . ___________________________________________________________________ Modified: svn:mergeinfo Merged /subversion/trunk:r1442090-1445080 (and lots of other changes were made in that revision, too, as expected). I don't yet know what's going wrong, but likely something to do with subtree mergeinfo is causing the mergeinfo graph to think that was not a complete merge. - Julian
