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

Re: merging to refactored branch: implicit mergeinfo misbehaving?

From: Tyler <tyler_at_cryptio.net>
Date: Thu, 19 Mar 2009 08:53:42 -0700

I apologize for "elevating" this to dev@, but I've not gotten any
responses on user@ and I believe this behavior is either a bug (in which
case I will open a bug) or a weakness in the documentation (in which
case I will open a bug) or a fundamental misunderstanding on my part (in
which case I hope someone will open my brain and fix it :)).

Re: the case I mention where my colleague was worried about the
proliferation of subtree mergeinfo: it sounds like that impression was
created when every "rename" operation created subtree mergeinfo. Since
that bug was fixed, I'm hoping that the subtree mergeinfo will only
exist for the merge points in the refactored tree. If this is true, then
we can live with that mergeinfo on a few hundred files/dirs. However, I
still would like to understand why the approach laid out in this mail
isn't working.

Thanks,
tyler

On Tue, Mar 17, 2009 at 06:33:14PM -0700, Tyler wrote:
> I'm bumping this in hopes of getting some response. I recognize that
> there's a lot going on here and it may be confusing, so I've added a
> simple recipe to demonstrate what I'm talking about and hopefully spur
> some discussion.
>
> My test environment is svn client version 1.5.6 on 64-bit linux.
>
> The script does a simple refactor (a file named "oldname" on trunk
> is renamed to "newname" on a branch), then merges changes from the trunk
> to the branch. This approach works if I allow svn to create subtree
> mergeinfo, but when I try to cheat and record mergeinfo only at the top
> of the tree (as I show in the recipe script), I get conflicts. When you
> run the script, you should see a bunch of svn output and then a conflict
> during the second merge.
>
> The script is included inline at the bottom of this email.
>
> (Note that this script will potentially do bad things to any pre-existing
> directories you have called /tmp/repo or repo in the directory where you
> run the script.)
>
> Why does implicit mergeinfo not work for me here? Have I misunderstood
> how it's supposed to work? Is my only option to live with mergeinfo
> scattered throughout my source tree?
>
> Thanks,
> tyler
>
> On Wed, Mar 11, 2009 at 02:52:11PM -0700, Tyler wrote:
> > 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
>
> #!/bin/sh
>
> # clean up
> #rm -rf /tmp/repo
> #rm -rf repo
>
> # initialize the repository and get a working copy
> svnadmin create /tmp/repo
> mkdir importdir
> echo "this is a source file" > importdir/oldname
> svn import importdir file:///tmp/repo/trunk/ -m "initial"
> rm -rf importdir
> svn mkdir file:///tmp/repo/branches/ -m "create branches dir"
> svn cp file:///tmp/repo/trunk/ file:///tmp/repo/branches/branch1 -m "create branch"
> svn co file:///tmp/repo
>
> # refactor the branch
> cd repo/branches/branch1
> svn mv oldname newname
> svn commit -m "refactor the branch"
> cd -
>
> ### FIRST PASS
> # change the trunk
> cd repo/trunk
> echo "line added on trunk" >> oldname
> svn commit -m "add line on trunk"
> cd -
>
> # merge change to branch
> svn merge -r1:HEAD repo/trunk/oldname repo/branches/branch1/newname
> svn propdel svn:mergeinfo repo/branches/branch1/newname
> svn commit repo/branches/branch1 -m "merge to subtree in branch"
> svn update repo/branches/branch1
> svn merge --record-only -r1:HEAD repo/trunk repo/branches/branch1
> svn commit repo/branches/branch1 -m "record-only merge to root of branch"
> svn update repo/branches/branch1
>
> # show the state of mergeinfo in the tree
> echo "### here is the output of svn propget svn:mergeinfo -R repo/ ###"
> svn propget svn:mergeinfo -R repo/
> echo "### end output ###"
>
> ### SECOND PASS
>
> # change the trunk
> cd repo/trunk
> echo "second line added on trunk" >> oldname
> svn commit -m "add second line on trunk"
> cd -
>
> # merge change to branch
> svn merge -r1:HEAD repo/trunk/oldname repo/branches/branch1/newname
> svn propdel svn:mergeinfo repo/branches/branch1/newname
> svn commit repo/branches/branch1 -m "merge second change to subtree in branch"
> svn update repo/branches/branch1
> svn merge --record-only -r1:HEAD repo/trunk repo/branches/branch1
> svn commit repo/branches/branch1 -m "second record-only merge to root of branch"
> svn update repo/branches/branch1
>
> # show the state of mergeinfo in the tree
> echo "### here is the output of svn propget svn:mergeinfo -R repo/ ###"
> svn propget svn:mergeinfo -R repo/
> echo "### end output ###"
>
> # clean up
> #rm -rf /tmp/repo
> #rm -rf repo
>
Received on 2009-03-19 16:56:09 CET

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