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 choice.
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.