The Subversion Mistake

While I don't disagree with the author's assertion that Git would much better support the kind of workflow he described, I think it's going a little far to categorically deem Subversion a "mistake" in all situations, 100% of the time. Subversion's relative simplicity compared to Git, as well as the toolchains built around it, hold a lot of appeal for certain applications.

For instance, we are a telephony consultancy that provides a lot of backend operational support to VoIP service providers. We did switch to Git for internal code development, but as part of most of our daily bread, we do a lot of configuration and provisioning changes to customer network elements, and we use Subversion for that because it's absolutely perfect. Managing configuration changes--even pseudo-programmatic ones--is a natural fit for Subversion, in the sense that a commit is simply a log of the cumulative effect of changes since the last commit, a statement about change that has taken place in a particular interval of time.

This type of management does not typically require branching, complicated merges, etc. The goal is simply to keep a running archive of configuration snapshots. Doing all that with Git, with its two-stage commit process (if you intend to use it in a centralised way) and rather inferior stock post-commit hook scripts wouldn't be worth the pain. Plus, in configuration management it's really helpful to be able to refer to revision 346 on an emergency conference call for a phone switch outage at 3 AM, rather than a long digest string.

Use the right tool for the job. There are relatively few things that are unequivocally "mistakes." A great deal of what passes for "factual" evidence in support of tool dogma is rooted in the forces of custom, habit and culture. There's nothing wrong with that; it's just something that should be kept in mind.

SVN is wonderful software. It is a quantum leap above "no version control" and tortoiseSVN is probably the best GUI available for getting value out of version control prior to understanding it. That said, magical goodness awaits you if you use DVCS instead.

The reason for the title of my posting is not to call 'Subversion A Mistake.' It was because of something Linus said in his video (which I highly recommend you watch). Basically, what he said is that if you can't trust your VCS to have the code in it that it should (and verifiable via hashes), then that is everything. I agree.

The Subversion Team, who are all great people and _really_ smart, made a huge mistake with adding mergeinfo to 1.5. It is a trainwreck of pretending to be able to do merges reliably, but in reality, it plain doesn't work. I talk about two specific cases where it breaks down in my posting, but there are many more.

Subversion has a lot going for it, I just think that the mergeinfo feature should just be thrown out and reworked from the ground up. My guess is that it will never happen as people will move on to newer and better systems, like git.

The most frustrating aspect was it seems that, while far from perfect, using Subversion as intended, in your case and ours, would be 1/10th as painful even while introducing a few issues of its own. The explanation I always got was "long before you came on board we used Perforce but we switched to Subversion because it's open source but we still want to use it like it's Perforce." You seem to have reasoned about your change quite a bit more than this, so I'm interested in hearing why you think you need to do things this way.