subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Bischoff <>
Subject Re: How to merge a rename of a folder
Date Tue, 09 Oct 2012 19:10:41 GMT
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 <> 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

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



View raw message