On Fri, May 10, 2013 at 11:23 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, May 10, 2013 at 04:14:36PM +0100, Philip Martin wrote:
>> The 1.7 files
>> were renamed in 1.8 to
>> 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
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
Received on 2013-05-10 17:31:50 CEST