Throwaway code under source control? To many Subversion users this may sound a bit OTT. But here are a few things that you need to consider about throwaway code:

  • It frequently needs to be debugged;
  • It frequently needs to be diffed;
  • It frequently needs to be rolled back to an earlier state;
  • It frequently needs short experimental spikes to try out alternative approaches;
  • It frequently needs to be bisected;
  • It frequently needs to be re-used;
  • It frequently turns out not to be as throwaway as you expected.

In other words, even for throwaway code, source control still has a lot to offer. And Git makes it so lightweight and seamless that within a few weeks, you find yourself doing exactly that. All you have to do is:

  1. Type git init
  2. Drop in a standard, peer reviewed .gitignore file
  3. Type git add -A && git commit

By contrast, just getting code under source control in Subversion in the first place is a cumbersome, heavyweight process. Subversion can not create a versioned working copy for existing code in-place in a single step. To get your code under source control, you have to:

  1. Set up a suitable repository if you haven’t already done so
  2. Allocate an appropriate folder in said repository
  3. Create a branches/tags/trunk structure
    • People often skip this step, only to regret it later.
  4. Import your code into said repository
  5. Painstakingly ignore everything you don’t want to check in
    • One folder at a time, often getting it wrong.
  6. Check out your code into a new, empty folder
  7. Replace your old folder with the new one
  8. On Windows, close down command prompts, text editors, and all sorts of other mystery processes that have opened up file locks on your original code for no apparent reason and try again.

Because the bar is much higher, Subversion users almost never put throwaway code under source control. In fact, they often fail to put not-so-throwaway code under source control either. It is very common for Subversion shops to have code running in production for paying clients that is not under source control anywhere.

I mentioned last week that if you are interviewing a candidate and they don’t have any Git experience, that is now a serious cause for concern. But why is this?

If a lack of Git experience were the only problem with an interview candidate, it wouldn’t be a problem. It can easily be made up with some training and mentoring. However, a lack of Git experience usually isn’t the only problem with an interview candidate. Increasingly, it raises serious questions about what other skeletons you might find in their cupboard.

The fact of the matter is that Git is now the lingua franca of source code management systems. It is the primary means by which developers communicate and share code with people outside their own teams. As such, it is now an essential core competency for any working software developer — just like recursion, or object oriented design patterns, or core data structures, or algorithmic complexity, or unit testing.

If you’ve just never got round to learning how to use it, you are simply not keeping your skills up to date, it’s as simple as that. On the other hand, if you have made a serious effort to understand it but failed, I would question whether you really have the aptitude necessary to do your job. Yes, Git does have some accidental complexity, but it’s nothing compared to what you have to handle in other aspects of software development.

In both cases, it also means that you aren’t interacting with the wider software development community beyond your own team: you simply can’t do so these days without using Git one way or another. This in turn is a warning sign that you’re likely to be sticking to and promoting best practices that are outdated if not outright discredited, because your view of what works and what doesn’t has a much slower feedback loop. If you’re a .NET developer in particular, it also means that you’re likely to be “pretty much a Microsoft-only guy” — the kind of person who won’t touch anything that doesn’t enjoy the imprimatur of MSDN, Visual Studio, and Team Foundation Server.

Oh, and in case you hadn’t noticed, Git does enjoy the imprimatur of MSDN, Visual Studio and Team Foundation Server — and has done so for two years now.

Most importantly though, it means that you are less visible, and therefore less likely to come to the attention of potential employers. Sure, you can apply through regular means, but this way, your CV is far more likely to end up in a pile of thirty other identical-looking CVs, and when your potential employer is filtering CVs to figure out who to call in for an interview, unless you have something that makes you stand out from the crowd — such as an active GitHub account — you’re effectively entering into a complete lottery. Do you really want to do that?

Some companies insist on standardising on a single source control platform so that they can have a single set of practices and cut down on training costs.

If you are doing this, and your standard is Subversion, then I have some bad news for you. Your standard is out of line with the rest of the industry. There is now to all intents and purposes a de facto industry standard for source control, and that standard is not Subversion.

The industry standard is Git.

Sure, it may not be a de jure industry standard, in the sense that it doesn’t (yet) enjoy the imprimatur of standardising bodies such as the IEEE, the ISO or the W3C, but there is no denying that it is overwhelmingly the de facto lingua franca for source code collaboration and communication.

You see it in the way that almost every actively developed open source project has now moved to GitHub. Even Microsoft, open sourcing the .NET framework, has used Git and GitHub, rather than TFS and CodePlex, to do so.

You see it in the way that popular commercial SCM solutions such as Perforce, Team Foundation Server and Plastic SCM now support Git directly out of the box. They’ve had to do so simply because it’s the only way you can retain market share as an SCM vendor these days.

You see it in the way that the three main companies behind Subversion — CollabNet, Elego and even one-time arch-Git-sceptics WANdisco — now offer enterprise Git solutions as first-class products.

You see it in the way that most new products coming on the market — such as Windows Azure — make it the preferred option if not the only option.

You see it in the way that Git has developed popular standards and best practices to a way that no other tool has done. There is Git-flow for branching and merging workflows. There is a standard for how to structure commit messages. There is a standard source for file ignore patterns.

I call these standards because they aren’t just random blog posts but widely used recommendations that have an increasing level of tooling support.

As for training costs, every developer that you hire should have at least some Git experience by now. If you’re interviewing a candidate who hasn’t, that is now a serious cause for concern.

Subversion enjoyed several years as the most widely used source control system. From about 2007 through to 2013 or so every survey around put it as the market leader, at its peak enjoying a market share of over 50%.

In the past couple of years, things have changed…somewhat.

Here are the figures from the 2015 Stack Overflow developer survey:

  • Git: 69.3%.
  • Subversion: 36.9%
  • TFS: 12.2%
  • Mercurial: 7.9%
  • CVS: 4.2%
  • Perforce: 3.3%
  • Other: 5.8%
  • None: 9.3%

No survey has ever given Subversion a market share of nearly seventy percent. The highest I’ve seen was 58.3% in the 2010 Eclipse Community Survey. By 2014, its market share in that same survey had fallen to just 30.7%.

Subversion 1.9 is at last approaching its final release.

It is a year late, having originally been “tentatively” slated for release in Q2 2014. We were promised various largely cosmetic features, most of which are now on the roadmap for version 1.10 or later. It is probably the most underwhelming release ever, delivering almost nothing other than under-the-hood changes that offer no significant benefit to your day to day workflow whatsoever. There’s still no shelving or checkpointing, still no bisect tool, and branching and merging is still a third-rate, error-prone, off-putting experience.

What of previous releases?

Subversion 1.7 was supposed to be the big one. Originally slated for release in the summer of 2010, it promised us a whole slew of “Git-like” features. It was eventually released in October 2011, fifteen months late. The “Git-like” features? An end to the .svn detritus throughout your working copy, and a faster wire protocol.

Subversion 1.8 was originally slated for release “nine months after 1.7.” We were promised shelving/checkpointing, repository-dictated configuration, and various other bits and bobs. It was eventually released in June 2013, almost a year late, with half its promised features bounced out. What did we get? An improved merge algorithm — which still doesn’t solve the deeply ingrained, fundamental problems with svn merge.

What of Subversion 1.10? It is “speculatively at best” slated for “2017?” What will make it to that release — if that release even happens — is anybody’s guess.

This is another of those crazy things that Subversion diehards say to justify not switching. They reckon that just as they’ve switched to Git, another cool new thing will come over the horizon and steal its thunder.

Of course, this is just another version of the mentality that says “Git is just the latest cool new thing” or “I’ve never had a problem with it”—both of which, as we’ve already seen, are complete and utter tosh. Besides, there’s a simple response: you’ve been saying that for seven years now and it still hasn’t happened yet.

Seriously, this argument is just idiotic. It’s like saying that you’re not going to adopt jQuery for your website because something else will come along in a couple of years’ time and supplant that. Has it never occurred to you that Git is older than jQuery?

Besides, it’s simply not going to happen. Git managed to steal Subversion’s thunder only because it offered significant ground-breaking innovations that addressed major shortcomings with Subversion. For something to steal Git’s thunder it would have to do the same, and there is nothing on the horizon that offers to do so. Besides, every major innovation in source control and ALM technology in the past eight years (and there have been several) has been achieved by building on top of Git rather than replacing it.

Even if it were announced today, a next-generation tool would face several insurmountable obstacles that did not exist in 2008. It would also need to overcome massive network effects that have resulted in Git becoming effectively the lingua franca for source code communication and collaboration industry-wide. It would also need to gain the support of numerous vendors of third-party software and services that have standardised on Git. You’re talking the best part of a decade at the very minimum before anything else gains enough mindshare to justify abandoning Git in favour of something else.

In any case, even if something did come on the scene in the next two years, so what? Yes, you’d be using a tool that had just been made obsolete. But if you’re still using Subversion you are already using a tool that has been obsolete for the best part of a decade. What other tools are you still using on new projects that are ten years out of date?

CodeLens is a really nice feature of Visual Studio 2013 Ultimate that shows you all sorts of information about your classes and methods. One thing that it can show is source control information — history, who last edited the method, and so on — inline, just above your method signature, in your text editor window. Think of it as log and blame/annotate on steroids.

1778.clip_5F00_image003_5B00_4_5D00_There’s just one proviso of course. You need to be using Git. Or TFS classic version control.

What’s that, you say? You’re using Subversion? Oh dear, too bad, you’re left out in the cold yet again.

But can’t someone such as AnkhSVN build an extension to add Subversion support? Sorry, nothing doing: CodeLens doesn’t expose a public API.

Sure, it may do in the future, but this is just one of many, many examples where using Subversion means you’re kept waiting for features that the rest of the industry has been enjoying for years.

Cloud-based web hosts are all the rage these days. It’s not hard to see why either: you can easily and quickly provision new servers, scale your websites up or down to suit changing requirements, or re-deploy whole apps in an instant.

One thing that makes this easy is the ability to deploy directly from source control. Simply by typing git push production master, you can trigger a build and release instantaneously.

Every cloud hosting provider these days supports Git for this. By contrast, few of them, if any, support Subversion.

I’ll just throw this one in because it’s a common misconception among Subversion diehards that using Git means using GitHub means you have to open source everything.

This is a misconception for three reasons:

  1. Git is not GitHub.
  2. Even if it were, GitHub provides private hosting plans.
  3. Even if you don’t want to use GitHub, there are still plenty of other Git hosting providers around.

Even if you aren’t happy about having your source code hosted in the cloud, you can still have your Git repositories hosted in your own infrastructure. For starters, GitHub provides a “host it yourself” enterprise version. Other options include GitLab, RhodeCode, Kiln, and Team Foundation Server 2013 or later.

One easy way to get Subversion hopelessly confused is to rename some files while one of your colleagues is editing them.

There are two ways of doing this: a right way and a wrong way. The right way is to ask Subversion itself to move them, using svn mv or the equivalent mouse gymnastics in TortoiseSVN. The wrong (and all too easy) way is to move them yourself and forget to tell Subversion.

Do it the wrong way then check them in to Subversion. Bingo! Either you or your colleague will get a bunch of tree conflicts — the nasty, messy, horrible kind of merge conflict that makes you think Subversion is being doubly sadistic today.

Even when you do get it right, Subversion still gets confused. Just the other week I got a whole lot of tree conflicts when merging two branches together — even though one of them had no changes at all. This kind of problem isn’t even exceptional.

With Git? It doesn’t matter. Git automatically detects renames.