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

Re: Merge, reintegrate, and merge with tree conflicts

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 24 Feb 2013 13:52:06 +0100

On Sun, Feb 24, 2013 at 12:14:04PM +0000, Andreas Tscharner wrote:
> > So what is the proper way to continuously perform the workflow we're
> > trying to do - that is pull changes from origin path into branch, push
> > changes to origin branch from branch, and repeat.
> >
> > Using bidirectional merge (without reintegrate) seems create severe
> > merge conflicts.
>
> Short answer: There is none (with SVN)

Sorry, not true :) Bidirectional merge is possible with SVN.

Subversion 1.8 will ship with an enhanced 'automatic' merge that
will make this very easy to do, see
http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge

But it is also possible with 1.7 -- it's just not widely documented
because the trick for doing it was discovered fairly recently during
1.8 development, while the "automatic merge" feature was being developed.

Quoting Julian Foad in http://svn.haxx.se/dev/archive-2012-05/0474.shtml

  * To merge again in the same direction as the previous merge
    => the existing "sync" merge will work.

  * To merge again in the opposite direction to the previous merge
    => the existing "reintegrate" merge will work.

So whenever switching directions use --reintegrate, and then keep using
plain 'svn merge' until you change directions again.
See the rest of Julian's post for details.

If you want to merge in this fashion, you should avoid subtree merges
(e.g. merging ^/trunk/foo to ^/branches/branch/foo), but always merge all
changes from the source branch (e.g. from ^/trunk to ^/branches/branch).

You should also avoid cherry-picking merges, i.e. never specify a
particular revision range to be merged, instead relying on merge-tracking
to merge all outstanding changes.

Note that both of the above restrictions exist in DVCS by design. So if you
are already considering DVCS as an alternative these restrictions should
not be an issue.

Please let us know if this approach works well for you.

> Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk).
> At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course)
>
> If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right?
>
> Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try.
>
> Best regards
> WENZEL Metromec AG
> Andreas Tscharner
> --
> Andreas Tscharner, Development
> WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland
> phone: +41 (0)81 257 07 00
> fax: +41 (0)81 257 07 01
> e-mail: mailto:andreas.tscharner_at_metromec.ch
> www: http://www.metromec.ch
Received on 2013-02-24 13:52:55 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.