[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Backporting changes in renamed files to 1.7

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 10 May 2013 11:31:18 -0400

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
>> 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

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
Received on 2013-05-10 17:31:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.