[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:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1258084

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

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:
trunk/
    toolbox/
        toolbox1.cpp

My refactored repo looks (partially) like this:
branches/
    branch1/
        libs/
            legacyapi/
                toolbox/
                    toolbox1.cpp

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
branches/branch1/libs/legacyapi/toolbox.

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
repository?)

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
http://www.collab.net/community/subversion/articles/merge-info.html,
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
branches/branch1.

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

If I leave the subtree mergeinfo intact, the merge completes
successfully.

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?

Thanks,
tyler
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.