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

Re: branching strategies in subversion

From: Stephen Butler <sbutler_at_elego.de>
Date: Mon, 28 Nov 2011 11:24:58 +0100

On Nov 28, 2011, at 10:11 , jes Struck wrote:

>
> Hej
>
>
> I started to investigate the branching strategies of subversion. to compare with Git, Mercurial and ClearCase.
> These three tools have an opportunity to branch out in a developer branch from which to deliver the trunk several times, so that such branches may be seen as developers industry instead of features industry. In Subversion, it seems that the second time you try to deliver the subversion dispose of any changes you've ever made any page on this branch
>

By "deliver", I presume you mean a reintegrate-merge, like

  svn merge --reintegrate ^/branches/mydevbranch

>
>
> So that second time i deliver it tries to deliver changes from Both Changeset A and B
>
> i would rather have it only took Changeset B?
>
> is this me that does not now how the correct way is to due it?

You can "revive" your branch (via the "svn merge --record-only" command)
after the first reintegration is committed to trunk (or wherever you copied
your developer branch from). This is described in the SVN Book at

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice

Tip: Your diagram shows only merges _from_ the developer branch. To
minimize merge conflicts, merge _to_ your developer branch early and often.

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync

Regards,
Steve

--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2011-11-28 11:25: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.