Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 16 Oct 2012 18:35:21 +0200
From: Stefan Sperling <stsp@elego.de>
To: Sven Uhlig <svenuhlig@web.de>, users@subversion.apache.org
Subject: Re: unexpected tree conflict on merge for same source file
Message-ID: <20121016163521.GJ6403@ted.stsp.name>
Mail-Followup-To: Sven Uhlig <svenuhlig@web.de>,
	users@subversion.apache.org
References: <507D4254.30808@web.de>
 <20121016160255.GI6403@ted.stsp.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121016160255.GI6403@ted.stsp.name>
User-Agent: Mutt/1.5.21 (2010-09-15)

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@410 ^/branches/prj@450 .

Sorry the above should have said:

  svn merge ^/branches/testing@410 ^/branches/A@450 .

This assumes that the delta between testing@410 and A@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@410 ^/branches/A@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@410 ^/branches/A@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@410 ^/branches/A@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.