Version Control is something that pretty much any developer will have experience using. Whether it’s a small app where changes to the code are maintained manually or a more massive project with branches and sub-branches that all need tracking, you can’t work in development without having to deal with version control.
There’s no denying the value of keeping track of who made changes to the code, and when. It helps to track down the source of bugs and prevents one developer overwriting changes made by another. In other words, version control helps keep your code under control.
That’s true for in-office development teams, and it’s also true for remote teams. A version control solution is something you need, no matter where your team is located.
But, as with most of the other tools we’ve discussed in this series, there are a few things you need to take into consideration when you’re using them remotely. So, here’s our rundown of the pros and cons of each of the major Version Control Systems (VCS).
Subversion
Subversion (usually just called SVN) is the VCS created by CollabNet and distributed by the Apache Software Foundation. It’s distributed as open source under the Apache license, meaning it’s free to download.
SVN uses atomic operations, that means that either all the changes are made to the source, or none are. This means partial changes won’t break your source code in the event of a connection error or similar. If you have developers accessing code from around the world via the internet, that’s an advantage.
Back in the old days of VCSs, when a developer was making changes to the code, that code was locked to any other developer. That helped prevent conflicts, but of course, it often means devs were locked out of bits of code they needed for long periods.
To get past that, SVN uses ‘merge-before-commit’ rather than locking. When a developer saves their changes, SVN will merge them into the repository copy. If that merge doesn’t work for some reason, the changes don’t take. It helps prevent partial merges from breaking your code. (If you’re a visual person then you might find this site useful to help you get your head around this concept.)
VCSs come in two flavors, distributed and centralized. SVN is centralized. What that means for you is that there is just one copy of the code repository. On the plus side, that means that all your code is stored on your servers, where you can control it.
The downside to that is, if your server goes down, then none of your developers can work. If your team works internationally, the connectivity becomes more of a concern. Not only do your servers need to be up and running during regular working hours for your home country, but they also need to be reliably up for workers in different time zones, too.
SVN is best suited to pretty linear development projects. It doesn’t handle branching as well as the more recent solutions.
Git
By contrast, Git uses a distributed repository. That means that every developer has their own, local copy of the repository which synchs with the master copy. If the central servers go down and your remote team is using Github or similar, they can keep right on working.
Git is also open source code, developed by Linux rockstar Linus Torvalds. Where Git really shines is in transaction speed. It’s a lot quicker than any of the other solutions, and if your team is working remotely, then anything that decreases the “save time” is an advantage.
Git takes a leaf out of Linux’s playbook and uses small binaries rather than one single application. So, you can personalize and alter it quite simply, giving your developers a lot more flexibility to have the CVS work according to their needs.
The downside of Git is that it is quite a steep learning curve for any developers who are used to SVN. There’s also less support for Git in Microsoft Windows when compared to Linux – for obvious reasons.
Rather than merge-before-commit, Git uses commit-before-merge. The repository will accept any changes submitted, but they’ll make a new sub-branch. Those changes can then be recognized as the new primary development branch or allowed to carry on as an off-shoot.
Mercurial
Mercurial was one of Git’s rivals; the two were being developed in the hopes of grabbing the Linux kernel development gig which eventually went to Git. Mercurial was released just a few days after its rival, and despite losing out on the Linux job, it’s done pretty well for itself.
While most other CVSs are developed in C, Mercurial was written in Python. That obviously makes it a hit with Python developers who feel more at home with its source code. Like Git, Mercurial is a distributed solution so you won’t hit problems if your central repository is offline.
There’s more crossover in features between SVN and Mercurial, so if your developers are familiar with SVN but you want a distributed solution then Mercurial has the edge. Drawbacks often cited for Mercurial include the fact that you can’t merge parents and the fact that it doesn’t use scripts, as Git does. That gives it a lack of flexibility that puts some people off.
Where Mercurial differs from SVN is when it commits changes. Mercurial, like Git, uses commit-before-merge. And while it may have the smallest market share of the three CVSs we’re discussing today, it is used by some heavy hitters, including Facebook.
Version Control and the Remote Team
It doesn’t matter how good your VCS is if your team hates it. So while you can make an on-paper decision about which is best for your project, if you’ve got a dyed in the wool SVN or Git hater (and both exist) then you’re probably better off letting them choose the system.
But, if we’re looking purely on paper, then we think Git has all the advantages when it comes to working remotely. First and foremost, you have that decentralized distribution. Whether your remote developer logs in every day or they code while backpacking in Nepal with no internet, they can still work on their local copy. And we like the way that Github focuses on asynchronous communication. That’s a big win for a distributed team.
When they get back to civilization, or your office servers come back up, all changes will be managed by Git itself, and you’ll soon have an up-to-date repository to deal with. But probably the most significant advantage that Git has is speed. When your staff is sending their data halfway around the world, the quicker the changes can be made, the better.
And, of course, if you need to find a developer to make all these changes to one of your existing projects – or kickstart a new creative vision altogether – then we’re happy to help you find the right person. Just give us a call.
A big, special thank you to Pablo Wolochwianski from Mindgeek and Angel Jakimovski for contributing to this article by answering our noob questions. You guys rock!
