On Thu, Feb 21, 2013 at 11:54 AM, Julian Foad <julianf...@btopenworld.com> wrote: > 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:
> 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. I assumed the mergeinfo graph was wrong, because I recalled him doing those sort of commits. What I was getting at, was if the merge graph is wrong, then maybe merge itself is having the same issue and not trying to do a reintegrate merge. -- Thanks Mark Phippard http://markphip.blogspot.com/
