DVCS’s Are Nice, But No Shame in SVN

Distributed Version Control Systems are quite popular, filling a need in this day of on-the-go and far-flung development teams. You can trace their history back quite a ways into proprietary solutions, but DVCS systems really gained traction when Linus Torvalds (of Linux, er, fame? goodness? godhood?) wrote git to manage Linux kernel development.

But if you’re still using Subversion, you’re far, far from alone. And in a lot of cases there are reasons not to switch.

CVS – First Big Jump
Sometimes history is useful. Remember the days before CVS? When you used some scabby system where you locked a file, worked on it, and went home? Only to get a call from a colleague that you “left it locked” and he was stuck?

CVS, for those who forget, was revolutionary in that you could have multiple people editing the same file at the same time, no locks. Oh, sure, there was a way to lock files if you worked hard at it, but CVS wanted you to take the leap of faith that it would merge things mostly correct. And it was right. I remember clearly feeling like it was magic that two of us could edit a file and it would just work.

CVS was a huge step forward in altering the version control portion of my workflow, and I bet that is true for lots of folks. But CVS had some problems. Primarily, cost of branching (in time) was brutal. So brutal, that most people with big projects didn’t branch. Compounding this was the hardship of merging branches successfully in CVS. Strangely, most of the merge hardship would push into Subversion.

Still, CVS was a win for its time. Lest we forget.

Subversion: Evolution In Action
The next jump was Subversion, a version control system most professional developers are intimately familiar with. Subversion, at first blush, was an very evolutionary step up from CVS. First among visible changes was the low-cost of making branches. Add in SSL/SSH connections, clients everywhere (including the popular TortoiseSVN for Windows), fast checkouts; there is a lot to like in SVN.

Finally, you could just spin out new branches willy-nilly, fast as can be. This promised the easy use of branching and merging, but alas, it was much harder to achieve than to talk about. Until around version 1.5, merging was a still a huge, counter-intuitive event. But the speed of branching was a big, big step.

SVN was fast and easy to install, so it came to be the gold-standard for the the online source code repositories. And hey, it worked, mostly.

Finally, as Eclipse came to dominate the IDE landscape, it shipped with CVS. Subclipse was one early SVN plugin, but it ate source files for me. That was a, hmm, problem. Then the Subversive plugin showed up, and though merging was a mess in the early days, as SVN 1.5 showed up and Subversive matured, things got a lot better.

Still, really big branch merges required bunny-hopping. Sigh. But for me, it always works.

Linus Turns His Hand, Change Ensues
Git was not the first distributed version control system, but git exploded the concept of DVCS across the software development firmament. Git was designed by Linus Torvalds to replace (if memory serves) Bitkeeper as the VCS for the Linux kernel. Linus, understandably, had certain requirements, and took a brilliant and hindsight-predictable (for Linus) approach to solving them. Git: it is first and foremost a fast filesystem.

Git was the wedge for popularizing Distributed Version Control Systems. Now we have Mercurial, Bazaar, and a bunch of others. DVCS is an established acronym. DVCS for the win!

Well, mostly. DVCS are characterized by a couple core concepts, things like each user keeping a complete copy of the repository, a lack of a required central repository, rigorous merge methodology (usually based on a concept like atomic changesets), and a lack of network traffic for common operations. There is lots to like there, and after playing with Mercurial for a while, it is really attractive to me as a developer.

But for my dev team, we’re sticking with SVN for now.

SVN: Still Gets It Done
In my job, I build/maintain a deductive database. Java code base, not a lot of gui stuff, lots of server stuff. Large automated test harness, lots of data, continuous testing. Fine. My devs are smart guys (all guys at the moment), and they could handle DVCS’s new concepts without much trouble. We branch when we need to, and it works.

But there is another half of the business, and they are not devs. We have a bunch of ontologists (logicians, modellers, really smart philosophers) who do services work. They have a remarkable tendency to generate datasets, sometimes somewhat large datasets. Occasionally really large datasets.

They check those suckers into SVN. We turn those suckers into Acceptance Test cases. In SVN.

The latest revision of the test and ontology repositories is assuredly huge. Checking out the entire history would be immense. My codebase is the tiniest portion of a normal developers’ workspace. You need the projects and test cases to run regression tests, so my devs don’t get to skip them.

Plus, ontologists are not developers. I don’t think I want to burden them with a more complex (if more elegant) VCS. They have enough to think about. When I started in this position, I had a hard time convincing the services team members that their models and datasets should be versioned at all; this was all alien to them. They are not developers. Smart as hell, but not software people.

Yes, I suppose we could look at some mixed-model of Mercurial with SVN adapters, or git over SVN, but, blech. Something else to go wrong, something else to maintain. I have code to write, things to build, problems to solve.

Don’t Feel Bad
So if you are still plodding along with SVN, don’t feel bad. You’re not failing. You’re not lazy. It does work. It might not be as sexy, but it does what it says it will do, and that is a virtue that can’t be underestimated.

And if you get a chance to try out Mercurial or git for a personal project, go for it! DVCS are pretty cool.

But SVN still works.

Explore posts in the same categories: Software, Tech

Tags: DVCS, Likes, Software Development, svn

You can comment below, or link to this permanent URL from your own site.