[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: James Hanley <jhanley_at_dgtlrift.com>
Date: Sun, 24 Feb 2013 07:57:14 -0500

I guess I should have read the next response in the thread before replying...

On Feb 24, 2013, at 7:52 AM, Stefan Sperling <stsp_at_elego.de> wrote:

> 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:57:53 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.