[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: John Maher <JohnM_at_rotair.com>
Date: Tue, 25 Sep 2012 08:19:26 -0400

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.


-----Original Message-----
From: Phil Pinkerton [mailto:pcpinkerton_at_gmail.com]
Sent: Tuesday, September 25, 2012 7:40 AM
To: users_at_subversion.apache.org
Subject: Branching best practice advice for an inherently complex

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

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.

Received on 2012-09-25 14:21:41 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.