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