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

merging to refactored branch: implicit mergeinfo misbehaving?

From: Tyler <tyler_at_cryptio.net>
Date: Wed, 11 Mar 2009 14:52:11 -0700

This is a follow-up (sort of) to this thread:

In short, I have a legacy repository from which we will be doing a few
more releases, but I'm also building a refactored repository for the

I am taking Holger's excellent advice and trying to solve my problems
with a branch instead of with a brand new repository. While testing this
approach, I encountered this issue.

My legacy repo looks (partially) like this:

My refactored repo looks (partially) like this:

Because of the refactoring, my merge command looks like this:

svn merge -r1:$LAST_REVISION trunk/toolbox/ branches/branch1/libs/legacyapi/toolbox/

This seems to work ok (though if I'm asking for trouble with this
approach, I'd love to hear about it!), but one annoyance is that merging
this way causes svn:mergeinfo to be created on the subtree

Since I have dozens of subtrees I will be merging into, this would
create a whole bunch of svn:mergeinfo properties scattered throughout
the tree. This is annoying, but even worse, one of my colleagues
suggests that these properties tend to grow and proliferate over time.
(Does anyone have experience with this? Is my colleague over-reacting or
does this have potential to be a real pain in a real-world-sized svn

So instead, we would rather get rid of all the subtree mergeinfo and
collect the mergeinfo at the top of the tree with --record-only. After
each subtree is merged, I would run:

svn merge --record-only -r1:$LAST_REVISION trunk/ branches/branch1/

Based on the info at
this should work because the subtrees will not have explicit mergeinfo,
but the merge process they should find implicit mergeinfo for the
subtrees by walking up the tree until it finds svn:mergeinfo set at

What I have found is that the implicit part doesn't seem to work. If I
carefully merge only new changes from legacy to refactored, that's ok.
If I try to merge everything and let svn merge figure out which changes
it has already merged and can now ignore, I get conflicts. The conflicts
look as though svn merge is trying to re-merge previously merged

If I leave the subtree mergeinfo intact, the merge completes

So, am I headed in the right direction at all? Am I misunderstanding the
docs or has something changed with subtree mergeinfo since it was
written? Does anyone have suggestions on what I should try next?

Received on 2009-03-11 22:53:01 CET

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

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