subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Butler <>
Subject Re: Trunk for "Prod" and a branch for "dev"
Date Thu, 01 Sep 2011 17:50:07 GMT

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.


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 |
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

View raw message