On Wed, Feb 27, 2013 at 5:04 PM, Julian Foad <julianf...@btopenworld.com> wrote: > Paul Burba wrote: > >> 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. > > Paul, thanks for investigating. While I'm glad to hear the automatic merge > was not the main root cause of the problem, it would make sense for it to > detect that merges in the opposite direction have been done and at least warn > the user.
Hi Julian, What are we going to warn them to do exactly? To explicitly use --reintegrate option? Because that would work in Stefan's case, so we should just do it rather than warn...unless you mean something else. I filed an issue for this: http://subversion.tigris.org/issues/show_bug.cgi?id=4329 and added a test which demonstrates a very simple version of the problem. I set issue #4329 a 1.8 blocker. While I think what Stefan is doing is somewhat atypical[1], if we are deprecating --reintegrate, then automatic merges should handle cases like this. After all, if we explicitly use the --reintegrate option the merge works fine. What do others think? [1] Doing *cherrypick* merges to effectively keep a branch in sync with trunk and then using an *automatic* merge to "reintegrate" the branch back to trunk. > It really doesn't make sense to proceed with the merging in a case like this. > > - Julian -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
