Branching best practice advice for an inherently complex environment - subversion-users

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Branching best practice advice for an inherently complex environment
Received-SPF: pass (google.com: domain of users-return-16305-subversion_users+garchive-53313=googlegroups....@subversion.apache.org designates 140.211.11.3 as permitted sender) client-ip=140.211.11.3;
Mailing-List: contact users-h...@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of lesmikes...@gmail.com designates 74.125.83.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E19D42CA-2F09-441E-856A-819C3859A...@gmail.com>
References: <E19D42CA-2F09-441E-856A-819C3859A...@gmail.com>
Date: Tue, 25 Sep 2012 08:09:00 -0500
Message-ID: <CAOAgVpz46cif0ExUFGrcis4DeBbuYxEziK56CmXu9BDHv5T...@mail.gmail.com>
Subject: Re: Branching best practice advice for an inherently complex environment
From: Les Mikesell <lesmikes...@gmail.com>
To: Phil Pinkerton <pcpinker...@gmail.com>
Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 25, 2012 at 6:39 AM, Phil Pinkerton <pcpinker...@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
     lesmikes...@gmail.com
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
