Branching best practice advice for an inherently complex environment
From: Phil Pinkerton <pcpinkerton_at_gmail.com>
Date: Tue, 25 Sep 2012 07:39:54 -0400
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,
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.
This is an archived mail posted to the Subversion Users mailing list.