Branching best practice advice for an inherently complex environment

[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 ; 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.

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 ?

What is a good example for controlling massive changes in multiple branches, merges to trunk and maximizing tags?

Have RTFM'd but need to convince the powers that be a change is needed that will also handle frequent changes in a very dynamic development environment.

I am still trying to fully understand this environment and attempt to turn it around as quickly as possible.

Any examples and or suggestions to produce a convincing argument would be useful.

Thanks

[John Maher]

I feel your pain. The only thing I can think of would be to demonstrate
a merge with no conflicts. Then show them what you have to do with the
90% conflicts. You can then explain how much development work can get
done if you do not have to resolve the conflicts.
How often do you merge? One mistake I made was not merging often
enough. A daily merge would not be a bad idea.

John

[Ulrich Eckhardt]

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.
**************************************************************************************

[Les Mikesell]

On Tue, Sep 25, 2012 at 6:39 AM, Phil Pinkerton <pcpin...@gmail.com> wrote:
> 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 ; 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.

What's the goal here? That is, is there some reason for maintaining a
bunch of slightly differing versions or is the intent for the
developers to work together and take advantage of each other's work?
If it is the latter, it would be better to just commit to the trunk
and resolve conflicts as they happen. In any case, you probably want
to merge the changes you want to keep to the trunk and make the trunk
the parent of the next branch instead of getting generations apart.
It is also very easy and productive to add a continuous integration
build server like Jenkins to automatically run builds and tests to
make sure that commits don't break anything.

> More branches are expected, changes and lack of frequent sequential merges is out of control, releases are scheduled monthly.

Branches make sense ahead of releases since that is one place where
you may need to maintain differences as the trunk continues. But in
that case you often won't do a full merge later, just any needed
bugfixes, then tag the release from there.

> 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 ?
>
> What is a good example for controlling massive changes in multiple branches, merges to trunk and maximizing tags?

If you haven't done it already, one thing that can help is to separate
out any components that can possibly be treated as libraries into
their own project-level trees with a separate branch/tag structure
that the application(s) can access with svn external references.
This lets you stabilize the interfaces at tagged versions so the
applications aren't affected by subsequent changes in the libraries
until the next tag is released and the application changes its
external reference to use it. This will help with the scenario where
you really do want differing versions to be maintained simultaneously
and can isolate the developers working on different parts from each
other to a certain extent.

> Have RTFM'd but need to convince the powers that be a change is needed that will also handle frequent changes in a very dynamic development environment.
>
> I am still trying to fully understand this environment and attempt to turn it around as quickly as possible.
>
> Any examples and or suggestions to produce a convincing argument would be useful.

Good testing procedures are what make good software, so whatever you
use should be wrapped around your QA and release testing process to
make sure that the versions released are exactly what have passed
testing. (Typically trunk->release-branch->release-tag)
Individually tagged components may help with this if they can be
tested separately since portions of the code may not change between
releases even though there is work in progress on the component
trunks.

--
Les Mikesell
lesmi...@gmail.com