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

Re: Branching best practice advice for an inherently complex environment

From: Ulrich Eckhardt <ulrich.eckhardt_at_dominolaser.com>
Date: Tue, 25 Sep 2012 14:22:46 +0200

Am 25.09.2012 13:39, schrieb Phil Pinkerton:
> Looking for convincing guidelines to change some rather poor
> practices
>
> Scenario : Project has multiple branches with frequent changes by
> several different developers, merging back to trunk is infrequent and
> when done merge results in 90% conflicts.
>
> simple example: Project A1 (trunk) copied to branches B1,
>
> B1 gets a few changes and is copied to B2,
>
> B2 gets some changes and B2 is merged to trunk,
>
> trunk gets copied to B3, B1 is merged to B3 and copied to B4
>
> B2 gets more changes, B2 is merged to B4, B4 gets more changes, B1
> gets more changes.
>
> messy I know ;

Indeed. Normally I would say: Merge more frequently, use a continuous
integration approach for testing the trunk, reduce complexity. Also,
consider working on the trunk directly because having small conflicts
and breakages early is better than having big ones later. It isn't
unusual to pull changes several times a day and also to commit that
often. Note that you can always update to an earlier revision while the
other guy that messed up the trunk fixes things.

> the big mess is B1 needs to be tagged and built and
> released but of course the merge to trunk will be full of conflicts,
> meanwhile B3 has more changes as does B4 and B4 needs to merge to B2
> so B2 can be tagged built and released.

Now, here are some requirements that you know but you don't tell.
Actually, here I would first try to put down the actual requirements and
then think about how to best achieve those with SVN. Maybe if you shared
them, someone will be able to suggest different approaches. In
particular, I wonder why so much branching is going on and why merging
is done in such a crazy way across different semi-related branches.
Typically, merging is only between the branch and its parent, not a
grandchild and some uncle.

> More branches are expected, changes and lack of frequent sequential
> merges is out of control, releases are scheduled monthly.
>
> My thoughts are this will get worse before it gets better, any
> experienced users who have complex environments have an idea on how
> to turn this around to use best practices ?

You need a release manager. The task of this person is to decide which
changes go into which release/branch and also monitor that changes go
where they are supposed to. Typically, that will be a team leader in
your company, but it doesn't have to be one that fully understands the
technical aspects of the changes. Using a ticket tracking system also
helps, SVN integrates with a few of them.

Good luck!

Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Received on 2012-09-25 14:23:23 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.