TL;DR; Subversion is rapidly becoming an obsolete tool that hampers fast iterations and lean development.
Much has been said about the different version control systems (VCSs) out
there, and since a VCS is such a standard tool in a developers toolbox, the
debate around the different systems is subject to personal taste, and can
easily drift to flame wars. I’ll try to describe, as objectively as possible,
why SVN wasn’t good for us, and why we’re switching to git.
Subversion has always been our version control system, in my current startup.
When setting up an intial SCM environment, choosing SVN is a no-brainer. It
is, arguably, the most easiest VCS to set up, and it has an extremely moderate
learning curve. The tools available for SVN (namely, TortoiseSVN) have helped
make it the default choice for any new software project.
However, we’ve reached the conclusion that SVN is not suited to support our
development processes. The core development team consists of 7 developers with
nearly orthogonal responsibilities, for most cases. This means that developing
new features usually encompasses more than one developer. The only place devs
can collaborate is on a mutual branch. Not only that, but just like most web
startups, we iterate fast. We need the ability to be agile.
Additionally, we take testing very seriously, and all new features must be
thoroughly tested on staging servers before being pushed to production. So
basically we’d want the flow to go something like this: create new branch for
feature, hack-hack-hack, switch staging server to branch for testing, merge
into trunk and push to production.
Unfortunately, from our experience, we’ve always had issues with branching and
merging in SVN, to the point that we try to avoid doing them in the first
place, at all costs. This lead to devs working directly on the trunk, pushing
features to production that haven’t been tested thoroughly.
Empirically speaking, we’ve had two major gripes with SVN that derive from the
fact that SVN does not track commit history as well as other systems. The
first symptom we’ve experienced is very coarse conflicts. This can be shown
very easily in the following scenario: consider a file with two lines on two
branches, one with “1 2” and one with “1 3”. Clearly the first line is common
(even if they branched out at the same time, that the file had only this one
line!) , but SVN will not recognize this, and consider the entire block as a
conflict. This expands to very coarse, very nasty, conflict blocks which
optimally could be much more specific.
The second scenario we were able to reproduce was updating the branch from
trunk before merging back into it. If not done properly, with manual noting of
revisions (pre SVN 1.5), SVN will have no notion of branch updates. For
example, pulling from trunk to branch will result in conflicts - cool, no
problem. But if not done carefully, merging the branch back into the trunk
will result in the exact same conflicts that need resolving once again! Again,
not to say that proper merging is not possible in SVN, but this process was
extremely tedious, and prone to human errs.
Also, since branching is not intuitive in SVN, we avoided creating a separate
branch for proper integration - which means that final integration was always
done on the trunk. This meant that while integration was being tested on the
staging severs, developers could not push new changes to the trunk -
effectively halting development for periods extending up to hours a day.
So it was clear our processes are flawed, but why choose git? True, many of
the modern DVCS, such as mercurial and bazaar, support proper
branching/merging. But git is the tool most of us have had experience with.
Basically, the entire migration process is relatively easy from the technical
standpoint. The main risk in switching to git is having each dev learn the new
flows, and get used to them - and from that perspective, git was the logical
Important to note that we do not really care about the distributed nature of
git. We look at git as a toolbox that allows us to implement any version
control flows that we want.
In following posts I’ll describe how we plan to use git in a semi-centralized
manner, including a branching model that fits an agile web startup.