I've been a Subversion (SVN) user going on 9 years now. It's been a great solution for source control throughout my career and I've implemented it at each stop along the way. It's easy, reliable, and straightforward. Now it's time to say goodbye.
The decision to move away from SVN is not one made because of any dissatisfaction with the system, which makes leaving it even harder to do. My team and I really like centralized version control and the fact that we never even need to think about SVN. We perform an update, we perform a commit, branch here and there, and that's it. While coding, it doesn't even cross our minds. So why abandon it? One word: Tooling.
In my opinion, tooling is one of the most underrated factors in development. Great tools help you produce better code with fewer errors more quickly. It's the reason I'm so big on .NET development. Visual Studio + .NET are the most amazing IDE and framework out there. I'd have words with anyone who says they're writing better code in notepad than in an IDE. But I digress.
Tooling, or the lack-thereof, for SVN is limited. There are a pile of 3rd party plugins for different IDE's and desktop OS's but no standard support for SVN. At my company we're developing in XCode (terrible SVN support), Visual Studio (weak 3rd party support), PHPStorm (good!), on Macs, PCs, and even some Linux sprinkled in there. The disparity is too great and has been a nuisance. What's more is that as programs and IDE's are upgraded or as new ones come along, we're seeing even less support for SVN out of the box. Before you say it, I know we could just use the command line on all platforms, but we had been accustomed (read: lazy) to tools like TortoiseSVN etc.
But there's one system that they're all supporting: Git.
Everything is supporting Git these days, right out of the box. It's being tightly integrated into pretty much every coding tool. It's even got strong support in Visual Studio using the same Team Explorer as Microsoft Team Foundation Server. It's become pretty clear that the tides of source control have shifted toward Git, and I'm not one to be left behind on old tech.
Our team had only dabbled in Git up to this point, really just via GitHub for some of our open source projects. We are experts in SVN though so we probably don't need to know much to start using Git right? WRONG. The difference between SVN - a centralized version control, and Git - a distributed version control, is huge. We got ourselves into trouble via false assumptions almost immediately. We had second thoughts. It was then that we realized we needed to sit down and fully learn Git before going any further. With SVN, the learning curve was small. We could get a newbie up to speed in like 15 minutes with the basics and they couldn't do much damage. With Git, every member on our team had to spend hours reading tutorials/guides and watching videos. Unleashing a team member on Git without a proper understanding of the workflow is downright dangerous.
If you want to get a grasp on Git, our team watched these videos which were very helpful:
- Section 01 -> Choosing the Right Version Control
- Section 03 -> GIT Basics
- Section 04 -> Git Fundamentals - Part 2
- Section 04 -> Git Fundamentals - Part 3
Tip: If you click on the video player cog, you can set the playback speed to Fast
We also used this website to learn and sandbox Git: http://pcottle.github.io/learnGitBranching/
And finally, based on many recommendations, we adopted this strategy for Git workflow in our team: A successful Git branching model
Working with Git
Ironically once we all understood Git better, the command line became our tool of choice for working with Git (except for conflict resolution of course). The way that Git operates has fundamentally changed the way that we think about version control. Instead of being an afterthought and in the back of our minds, it's much more at the front of our thinking, even as we code.
It took a week or so for us to get comfortable with the new workflow but now everyone is all in on Git. There are things we like more and things we like less than SVN but overall it's here to stay for us.
In the next part of this series I'll talk about how to migrate an existing SVN project to a new Git repository while maintaining version history. I'll also talk about the Git web server that we're using, GitLab, which has been amazing so far.