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

Re: How to merge a rename of a folder

From: Martin Bischoff <tinu44_at_gmail.com>
Date: Tue, 9 Oct 2012 21:10:41 +0200

Thanks a lot for the detailed information. Please see below for some
additional questions.

On Tue, Oct 9, 2012 at 7:05 PM, Stefan Sperling <stsp_at_elego.de> wrote:

> On Tue, Oct 09, 2012 at 05:23:30PM +0200, Martin Bischoff wrote:
> > I have a project which is being developed on /trunk, and at the same
> time I
> > have a branch (/branches/1.x) for maintenance of version 1.x.
> >
> > Now I'd like to rename a folder of the project, e.g. /trunk/a to
> /trunk/b.
> > The same folder should also be renamed on the maintenance branch, so that
> > future bugfixes (made inside /trunk/b) can be merged to the branch.
> >
> > If I merge the revision (in which /trunk/a was renamed to /trunk/b) to
> the
> > branch, then it seems that files inside /branches/1.x/b will then be
> > identical copies of the files inside /trunk/b at the HEAD revision. This
> > means, that for example, any changes made directly on
> /branches/a/text.txt
> > are then lost.
> >
> > Obviously I'm doing something wrong!
> >
> > What is the correct procedure to merge a rename of a folder to a branch?
> >
> > Should I rename the folder independently on both trunk and the branch?
> Will
> > I then still be able to merge changes from /trunk/b to /branches/1.x/b?
>
> Yes. See below for details.
>
> > BTW: I'm using the current version of TortoiseSVN, so I can't give the
> > exact svn commands that were used.
> >
> > Thanks a lot for any help.
> >
> > -Martin
>
> The following instructions work for me with the command line client.
> I'm making some assumptions though, not sure if these apply to your
> particular case:
>
> - The folder A is renamed to B on trunk in a revision I'll call N.
> Ideally, there are no unrelated changes in this revision, just
> the rename (not a strict requirement but it makes resolving
> the tree conflict much simpler).
>

That's what I did during my tests. Revision N only renamed the folder.

>
>
 - The branch has merged all desired changes from trunk up to revison N-1.
> It's Ok if you haven't merged *all* revisions up to N-1 from trunk to
> the branch. But any changes up to N-1 you desire should have been merged
> to avoid conflicts if revisions older than N-1 are merged in the future.
> So if there are any such revisions which haven't been merged yet, merge
> them now.
>

That's also fulfilled. All desired changes were already merged to the
branch.

>
> Given these assumptions, here's one way of merging the rename
> on the branch (there are others, but there is no need to talk
> about them if the below works for you):
>
> Get a working copy of the branch at HEAD.
> In this working copy, rename folder A to B. Don't commit!
> Instead of committing, merge just rN from trunk, using TortoiseSVN's
> "Merge a range of revisions" merge option, using just N for the
> revision range parameter.
>
> Two tree conflicts will be flagged.
>
> Here's what the above looks like in the command line client, with N=4:
>
> $ svn merge -c4 ^/trunk
> --- Merging r4 into '.':
> C B
> C A
> --- Recording mergeinfo for merge of r4 into '.':
> G .
> Summary of conflicts:
> Tree conflicts: 2
> $ svn status
> M .
> D C A
> > local delete, incoming delete upon merge
> A + C B
> > local add, incoming add upon merge
> Summary of conflicts:
> Tree conflicts: 2
>
> The first line showing M is a mergeinfo change.
>
> The incoming delete of A conflicts with the local delete of A.
> This happened because both sides (trunk, and branch) decided to
> rename A to B, and Subversion cannot yet tell the difference
> between a normal deletion and a deletion that happens as part
> of a move (which sucks, and we're trying to fix this, but that's
> a separate discussion). In this particular case, deleting A is the
>

Will the (hopefully soon-to-be-released) version 1.8 already contain some
improvements in that area?

> desired conflict resolution outcome. Since the working copy is
> already set up to delete A during the next commit, we can just
> mark the tree conflict on A as resolved:
>
> $ svn resolved A
> Resolved conflicted state of 'A'
> $
>
> Now, what about B?
>
> Check the URL of B in the 'Subversion' tab of the directory's
> properties dialog in Windows. On the command line you can use
> the 'svn info' command for this purpose. In my case this is:
>
> $ svn info B | grep Copied\ From\ URL
> Copied From URL: file:///tmp/svn-sandbox/repos/branch/A
>
> So clearly it's a copy from the branch, not from trunk!
> This happened because we renamed the folder before running
> the merge, forcing a tree conflict, so that Subversion won't
> add 'B' as a copy from trunk.
>
> You might also want to verify that the content in files with B
> still matches what you expect, just to make sure (and this is where
> things get more complicated if you also have other changes in rN...)
>
> Since the directory B is precisely in the state we want it to
> be in, we can also just mark the conflict resolved:
>
> $ svn resolved B
> Resolved conflicted state of 'B'
> $
>

Instead of merging revision N and resolving the conflicts, would a
record-only merge of revision N give the same result?

>

Now commit the entire working copy. This commit will mark revision N
> as merged from trunk and rename A to B on the branch. Future merges
> from trunk will expect a path B instead of A, and work as expected.
>
> For instance, merging r6 from trunk which changed a file B/zeta just
> works:
>
> $ svn merge -c6 ^/trunk
> --- Merging r5 through r6 into '.':
> G B/zeta
> --- Recording mergeinfo for merge of r5 through r6 into '.':
> G .
> $
>
> I hope this helps. If you have further questions feel free to ask.
>

Is the same procedure required when renaming files instead of folders, or
does this issue only happen when renaming folders?

Thanks.

-Martin
Received on 2012-10-09 21:11:14 CEST

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.