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




Reply via email to