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

Re: merge using same revision number - quick question

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 22 Apr 2013 22:59:30 +0200

On Mon, Apr 22, 2013 at 10:00 PM, Z W <mpc8250_at_gmail.com> wrote:
> Hi Johan
> Thanks for responding.

You're welcome :-). I'm putting the users list back in cc to keep it
in the loop. Please remember to use reply all for this reason.

> We didnt know of the subtree merging concept and you are right, we did
> perform some merges at the files level in the subdirectories.
> When you say
> "What might happen though is some elision (i.e. rearrangement) of
> mergeinfo: if you merge r345 at the root level, and it has previously
> been merged to all its operational targets with subtree merges (like
> in your example), SVN will remove the subtree mergeinfo, and just note
> that the entire r345 has been merged at the root level."
> In other words, if we now try to "re-merge" at the root level as you
> suggested, those previous subtree merges would not hurt, meaning messed up
> with double merges, right ?

No, it will not hurt. If everything works as advertised, this is a
perfectly supported use case (subtree merge tracking), and double
merges should not happen.

Feel free to double check by just trying it in a freshly checked out
working copy of your branch. You should be able to run the merge you
want to do, and then check what has happened by running 'svn diff'.

> We like to do it right this time the way you suggested.

Yes, establishing a policy of always merging at the "root level" (i.e.
avoiding subtree merges) makes things a lot simpler.

Another suggestion: previously in this thread you said you're using
SVN 1.6. I would highly recommend upgrading to 1.7 (at least for the
client(s) ...). The SVN client 1.7 has a lot of good improvements for
merge tracking. See:


Received on 2013-04-22 23:00:21 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.