Branching best practice advice for an inherently complex environment

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
Received on 2012-09-25 13:40:36 CEST