subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Reedick <Andrew.Reed...@cbeyond.net>
Subject RE: Shared branch vs single branch
Date Mon, 23 Sep 2013 23:49:48 GMT


> From: C M [mailto:cmanalyst66@gmail.com] 
> Sent: Monday, September 23, 2013 4:05 PM
> To: Les Mikesell
> Cc: Bob Archer; Subversion
> Subject: Re: Shared branch vs single branch
>
> Unfortunately, we are lacking on processes and there's a definite lack of product management.
> But coming back to  my original question: Are there any potential gotchas with using
a single/shared branch? For now, that's the only change the team (and leadership) is looking
to as the "solution".

Firstly, one branch only works if you only ever have one and only one development steam going
at a time.  This "never" happens because at a minimum, you need a branch to support production
fixes, a branch for QA fixes for the "final" release candidate, and a branch for the next
release, e.g.:
* /branches/1.0.1 - prod bug fixes for 1.0.0 in prod
* /branchs/1.1.0 - 1.1.0 is in its final round of QA testing, so only 1.1.0 bug fix work is
accepted
* /branches/trunk (aka 2.0 work)
In other words, don't ignore, gloss over, or otherwise lie to yourselves over the need to
support multiple branches and merging.

Secondly, everyone will still require training.  Multiple branches (see Firstly above) will
require training for everyone.  Even if you have the CM guy do the merges, you still need
to teach the developers how to avoid creating Evil Twins (i.e. a particular Tree Conflict.)
 An Evil Twin is created when you 'svn add foo.java' on both the trunk and on the branch,
instead of merging 'foo.java' from trunk to the branch.

Thirdly, you need process and project management.  If you can't track your work, even "single"
branching is going to fail hard, such as when you have to back a feature out of trunk due
to time constraints.  If you can't identify/track the work back to individual check-ins, then
you will have great difficulty in reverse merging a feature out of trunk and merging it to
its own branch.  If you can't assign work and/or manage requirements, then, technically, you
cannot, in good faith, decide whether single or multiple branches are right for you.

Fourthly, Semper Gumby; "Always Flexible."  Branching gives you flexibility.  Going with single
branching limits your ability to change, adapt to, or manage releases.  If you have lousy
requirements management, then single branching means you're more likely to wind up in death
marches, late nights, and relying on full regression testing (which takes time that you won't
have) to verify that you all haven't broken something stupid on trunk.  If I had lousy/incomplete/late
requirements then I would want to use feature branches to help mitigate the pain.

Fifthly, keep your resume up to date.  A good marriage counselor helps as well.  Keep in contact
with your company recruiter in case you experience higher than average developer burn out.
 Over-dramatic, but no process == inefficient work == making up the time with people's personal
time, i.e. late hours, weekend work, etc..


To actually answer your question, the pitfalls of single branching are:
a) people working on the same files will create conflicts during 'svn update'.  However, svn
locking can help reduce the pain.  Dividing up the work so that folks are working on different
parts of the software helps as well.  Communication is key when multiple developers touch
the same set of files.

b) having to remove code.  If a feature is unstable or cannot be completed in time, then you
will need to reverse merge it out.  Which can be more difficult with single branching over
feature branching.  Difficultly is increased the longer/bigger the release is, due to the
increased chance of interdependencies with the removed feature.

However, if you're doing Agile development (short release cycles/sprints, a small set of well
defined requirements for each sprint, etc.) then the dirty trunk approach should work mostly
easily.  However, the longer your release cycle, the greater your chances of having to rip
out a feature and the greater the difficulty it will be in doing so (due to dependencies,
larger set of QA test to run through, etc..)
 

> Our developers code on a Unix like platform and have little SVN experience to boot. The
idea of turning over merging to them seems to be a recipe for disaster. I would prefer to
let the CM team handle the merges and figure out what I did incorrectly to mess up the previous
merges.  

Go with the trained CM guy.  Tree conflicts in Subversion aren't exactly well documented and
require some experience to do correctly.  However, your CM guy can't merge based on business
logic, e.g. if something *shouldn't* be merged (such as a temporary hack) then you Someone(tm)
needs to work with the Merge Meister, i.e. have a merge party.

Good luck.  It doesn't have to be perfect, but the more up front planning you do, the less
of your life you lose to stress.  Also, defining a process is the first step towards process
improvement and a saner career.  =)

/soapbox off


Mime
View raw message