On Fri, May 10, 2013 at 11:23 AM, Stefan Sperling <s...@elego.de> wrote: > On Fri, May 10, 2013 at 04:14:36PM +0100, Philip Martin wrote: >> The 1.7 files >> >> subversion/svn/main.c >> subversion/svnserve/main.c >> >> were renamed in 1.8 to >> >> subversion/svn/svn.c >> subversion/svnserve/svnserve.c >> >> and this causes conflicts when backporting changes from trunk. On the >> branch 1.7.x-r1475724 this was resolved by doing a subtree merge and >> thus recording subtree mergeinfo. >> >> I now want to backport r1481010 and I'm wondering if using subtree >> merges is the best way to handle this. My first instinct was to do a >> whole branch merge and resolve the conflicts to leave a mergeinfo change >> on the root. Then I noticed that the 1.7.x-r1475724 branch had takes a >> different approach. Does it matter which approach is used? > > I would say just use whichever approach you like best.
Agreed. For a release branch I don't see that it matters. We won't ever merge 1.7.x back to trunk, so we don't need to worry about http://subversion.tigris.org/issues/show_bug.cgi?id=4255 Personally I prefer an approach that keeps that avoids new subtree mergeinfo, simply because it's easier to run 'svn pg -vR' on your branch root and get a quick idea what has been merged via visual inspection, but that doesn't matter much since 'svn mergeinfo -R' will happily deal with any subtree mergeinfo. > FWIW, I would also run the merge on the root, and then resolve > the tree conflict by running a subtree merge on the file itself. Or do an --ignore-ancestry merge on the file directly, then a --record-only merge on the root. No matter how you do it, it's a bit ugly, and we are only dealing with a single file here! > Or perhaps even applying a patch instead of running the subtree > merge ('svn diff', edit filename in patch file, and 'svn patch'). > > Maybe Subversion 1.9 will finally make this easier? :) -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
