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

Re: Trunk for "Prod" and a branch for "dev"

From: Stephen Butler <sbutler_at_elego.de>
Date: Thu, 1 Sep 2011 19:50:07 +0200

On Sep 1, 2011, at 18:25 , Brendan Flanagan wrote:

> All,
>
> One of our customers is implementing subversion and TSVN and they have
> decided on a repository structure that is slightly different than "the norm"
> and I wanted to check if it had any "flaws"?
>
> They support and develop enhancements to a purchased product (they don't
> have the source for the purchased product, only their enhancements).
>
> They want "trunk" to reflect the current Production Release of their
> enhancements only. They intend creating a branch called "Development" that
> the small number of developers will use day to day - i.e. they will add new
> enhancements, change existing code etc.
>
> Periodically they will merge some of the committed changes (from the Dev
> branch) back to trunk and effectively create a new "Production Release" and
> tag it.
>
> On the face of it I can't see anything wrong with this approach and it's
> different than others we use/have seen and doesn't follow the recommended
> approach of developing in the trunk and creating release branches - but is
> this structure/process going to cause any heartache for them? I guess it
> just doesn't feel right as it's different than anything we have seen before
> but I am struggling to come up with a strong argument against it.
>

If some percentage of changes on the development branch never get merged
to trunk, then that branch will slowly diverge from the trunk.

The developers would need to reverse any revisions on their branch that have
been rejected by testers. That's not as easy as it sounds, since reverse-merging
old revisions often leads to conflicts.

If the team is small and the code is stable, it's doable. Otherwise, there's too
much manual diff- and log-inspection.

Also, if they decide later to have more than one development branch, it will be
difficult to share changes among the branches. You'll likely see cyclical merging,
which doesn't work well in Subversion's model. Or developers will integrate
very late, which is risky.

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-09-01 19:49:21 CEST

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.