I’ve not been programming for all that long, but in that time I’ve used two
different version control systems. In my internship I used Subversion (SVN),
and in my personal life and open-source stuff I’ve used Git. I find the
relationship between the various major VCSes to be quite interesting, and
wanted to devote a little time to talking about them.
For the sake of fairness (and because I’m a Python hacker), I should point out
that the vast majority of the things I say about Git apply to Mercurial. I
have not used Mercurial very much at all, but my understanding is that the
general usage model for Mercurial is more-or-less identical to Git. Certainly
Mercurial and Git are both what is known as distributed version control
systems.
Woah, woah. Distributed?
Oh, yeah, I should probably go back a few steps. So, the reason I want to
compare Git and SVN is because the very different usage patterns the two tools
create is fundamentally based upon a single ideological difference. This
difference can be summarised as follows: in Git, no repository is special; in
Subversion, the central repository is special.
Traditional version control systems like Subversion use a system that is a bit
like a client-server model. You set up a central Subversion repository on a
server somewhere, and check your initial code into it. If you want a copy of
the codebase, you check out from that repository. At that point, you have a
copy of the code on your machine, but you cannot treat your local repo as
identical to the central repo.
Git (and Mercurial) differ in a single core idea: each repository is on equal
footing with every other repository. I can find any repository of a codebase,
clone it, and then have a completely functional repository on my machine. Any
code check-in is local, into the repository on my machine; I can create and
merge branches without affecting any other repository; and other people can
clone the repository on my machine and merge into any other repository. This
lack of central authority means that VCSes like Git are called distributed
VCSes.
Ok. Does this difference matter?
For me, yes. I have a habit (potentially an unfortunate one) of using VCS as
an indication of how ‘real’ my code is. This means that I tend to want to
check my half-finished code into souce control, including code that isn’t
passing tests, or even code that fails to build.
Subversion requires me to fight this tendency. Anything I check into source
control must run properly, because anyone who wants a copy of the code
will check out my changes. At my internship the build machines would check out
a copy of the Subversion repository to run the build, so I would have had the
added ignominy of breaking the build. This never happened to me, thankfully,
but the embarrassment would be…significant.
Git does not force this behaviour on me. If I feel I’ve made progress towards
a problem I can commit those changes into my local Git repository. This means
that if I make another change that ruins everything, I won’t lose those
changes. Once again, this has never happened to me, but it is the kind of
nightmare that ferments inside my twisted brain.
Another advantage of the local nature of Git is that the repository history
becomes flexible. As long as a change has not been pushed out to any other
copy of the repository, I can edit that change to my heart’s content. This
means that I can not only make half-baked commits into my Git repo, but when
I have solved the problem I can edit the previous commits I made. The number
of times I have done this is nearly beyond counting, and my Git log reads much
more cleanly than it would otherwise.
Editing the repository history must be done with caution, of course.
git bisect is a great tool, and it becomes significantly less useful if your
edited history makes certain commits fail tests. I hear that history editing
is a lot less common in the Mercurial community, but I can’t really speak from
experience.
Once I’ve become comfortable with my changes and edited the history so the
whole thing looks like I’m a sane developer instead of a crazy person who has
no idea what he’s doing, I can push the changes to some more public location.
Once I’ve done this I need to resist the temptation to edit those commits, as
if you do you end up making future merges hellish.
Oh yeah, merging.
Speaking of merging, anyone tried to do a merge in Subversion? Yeah, it’s not
fun. I’ve worked with some very, very intelligent developers on Subversion
repositories, and each one of them was apprehensive each time they had to
perform a merge.
This difficulty with merging causes an unwillingness to branch in Subversion
as well. Of course, institutional requirements mean that damn it, you will
make feature branches, whether you like it or not; but in my experience
these branches were used for large scale changes (e.g. new releases), not for
individual features.
Conversely, with Git I’ll create branches for features large and small,
because doing so has essentially no cost associated with it. This has the
added advantage of ensuring that I always have a copy of my code that will
definitely, absolutely work: the master branch.
So Subversion sucks. Why should it die?
Because it’s my belief that Subversion actively makes it difficult for
developers to develop. Your VCS should encourage you to version your code, and
to isolate your development. Subversion’s single repository nature discourages
the checking in of your code until you’re absolutely confident of it, which
causes SVN histories to be filled with enomous commits.
This reluctance to check in code means that the diffs between commits are
enormous, and then knowing which commit introduced a bug becomes almost
entirely unhelpful to the debugging process. Having debugged in just such a
circumstance, I can tell you that if I’d had git bisect back then my life
would have been significantly cheerier.
Similarly, the difficulty merging that Subversion introduces causes developers
to be reluctant to create feature branches for anything less than a really
significant change. This causes all the developers in a group to commit their
changes to the master branch. This wildly clutters up the history of the
repository, but more importantly, can put the repository in a state where the
default checkout fails to build.
Finally, you can’t commit when you’re unable to connect to the central
repository! This is so helpful it’s almost impossible to describe to someone
who hasn’t used it. Commits become fast and plentiful, and it becomes
incredibly easy to work away from your central repository.
I would optimistically like to predict the eventual death of Subversion. Much
like CVS is (almost) dead, Subversion will become increasingly less popular
for new projects. This will push Subversion first into being predominantly
used in industry (a state that is almost true already), and then into being
used only in legacy projects (why hello there COBOL!).
Subversion has been a highly useful tool for developers that was a significant
step forward from previous VCSes. However, the new wave of distributed VSEes
promises to make everyone’s life easier, and so I for one will be happy to
take Subversion out the back and shoot it in the head.