I recently started a new job, which gave me a reason to look at my choice of VCS. I’ve been using Subversion for several years now, but being a UNIX admin by trade, I never really cared about my VCS, just so long as it did it’s job. For the most part, it has worked quite well, and I’ve never quite seen the big deal about distributed version control. I was always of the view that you store your code on your filesystem of choice, and that VCS is just for archival storage of the code. In the worst case, you used it to roll back a change that didn’t quite work out so well. The new job was, not surprisingly, a Subversion shop, but I had started looking into a few DVCS’s out of curiosity. There was one part of my normal workflow that Made a DVCS quite appealing. My normal workflow when not connected to my VCS goes something like this: 1. Write some code 2. Get an off the wall idea that I may or may not want to
use/save, and may not even work
- Copy off my current code base, usually as a tarball
- Work on new idea
- If it works, keep it, if not, restore from my copy
After a few weeks of working with code for 8 or more hours a day, I decided that there had to be a better way of doing things. Steps three and five always seemed cumbersome to me. That’s where the “distributed” part of DVCS appealed to me. What finally convinced me to try out a DVCS was the fact that instead of doing the usual, relativly long, process of copying off my current code base, I could now just do a fairly cheap branch, and be on my way. And when I was done, I could just merge my feature branch back into my main branch. Or, if it turned out to be complete junk, I could just delete the branch, and pretend it never existed. For the curious, I chose Git as my DVCS, for one big reason. The Subversion interoperability provided by git-svn is head and shoulders above any of the other DVCSs I looked into. And since I have to check everything into a Subversion repository at work, this was a key feature for me.