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

Re: What branching patterns work with Subversion reintegrate merge?

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 21 Mar 2016 16:21:53 +0100

On Mon, Mar 21, 2016 at 02:23:06PM +0000, Bob Berger wrote:
> Thanks for your reply Stefan. It's very much appreciated.
>
> Before Subversion 1.8 made the reintegrate merge automatic, I was doing merges without the reintegrate option, which were, I suppose, inappropriate "complete merges". They were
> generally effective, but sometimes produced errors and strange conflicts. With Subversion 1.8 or higher, I am forced to cherry-pick, which may sometimes produce poor results if I pick the
> wrong cherries. I had regarded cherry-picking as error-prone and something to be avoided, but it's good to know that it's used successfully elsewhere.
>

The impression that you're forced to cherry-pick must be a misunderstanding.
You can still force the reintegrate merge in 1.8 and later by passing the
--reintegrate option. This still works, just as it did in older releases.
The option is deprecated because there is no general need for it any more,
but it is still available and forces the previous behaviour.

I would suggest looking at this problem in terms of a process problem,
instead of a Subversion problem. Which kind of merge is most effective
depends on the nature and purpose of the branches involved, and details
of the overall merge strategy (or "merge pattern").

From the ASCII diagrams in the svn merge help text you can tell which merge
scenario applies to a particular invocation of 'svn merge'.
I'd suggest drawing similar diagrams for your own project's workflow, using
forked lines to represent branches, solid arrows for complete merges, and
dashed arrows for cherry-picks. If you use cherry-picks, writing some example
revision numbers below the diagram might help, on a line from left to right,
so you can better visualize what will happen in the repository.

Then, figure out which svn commands are needed to implement each merge arrow
in your workflow. For assistance you could try some merge commands with a toy
project in a separate repository to verify Subversion's behaviour matches
what you expect. If the diagram becomes too complex to handle with simple
Subversion commands, try to simplify your strategy, or use the most general
merge invocation (2-URL merges, which can merge anything anywhere), sparingly,
where you must.
Received on 2016-03-21 16:22:09 CET

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.