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

Re: unexpected tree conflict on merge for same source file

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 16 Oct 2012 18:35:21 +0200

On Tue, Oct 16, 2012 at 06:02:55PM +0200, Stefan Sperling wrote:
> If you really must merge between unrelated branches, use the 2-URL
> merge syntax instead of the 'svn merge ^/foo' short-hand syntax and
> specify revisions for each of the 2 URL arguments to merge meaningful
> changesets. For instance, say you created '^/branches/A' from trunk in
> r399, and then made some interesting changes between r410 and r450 on
> branch A. You want to merge those changes into a completely unrelated
> branch called 'testing'. Try something like this:
>
> svn switch ^/branches/testing
> svn merge ^/branches/A_at_410 ^/branches/prj_at_450 .

Sorry the above should have said:

  svn merge ^/branches/testing_at_410 ^/branches/A_at_450 .

This assumes that the delta between testing_at_410 and A_at_450 contains
only changes that are unique to branch A, which will be the case
unless you merged changes from other branches into A between r410
and 450. You can check the delta with the following command:

  svn diff ^/branches/testing_at_410 ^/branches/A_at_450

If the delta contains changes you don't want to merge, you can either
run the merge anyway and resolve conflicts (if any), or try this instead:

  svn merge ^/branches/A_at_410 ^/branches/A_at_450 .

If the above gives you tree-conflicts either resolve them as appropriate
or try again with --ignore-ancestry:

  svn merge --ignore-ancestry ^/branches/A_at_410 ^/branches/A_at_450 .

If you throw away the 'testing' branch after testing anyway, the lack of
mergeinfo recorded during the --ignore-ancestry merge might not be
a problem.

Again, sticking to simple branching/merging patterns where all merges
happen between directly related branches makes things a lot easier.
Received on 2012-10-16 18:35:57 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.