Distributed version control is nothing to be scared of. It may be a lot simpler than a lot of people or ‘introductory tutorials’ have led you to believe.
- Distributed version control doesn’t force you into a new way of working. If you prefer a centralised approach, you can still do that. You could use it very much like you currently use svn if you want to, and yet you’ll still get the benefit of having a local history of revisions, allowing you to do a lot of things such as revert, diff, or even check in some code locally – without the overhead of network access.
- Distributed version control does not force you to have a mess of different branches of your code on different developers’ machines, with no clear indication as to which one is most ‘up to date’. You would still have a ‘main’ or ‘trunk’ branch on a server somewhere which represents the main focus of development. Developers get the added option of having new branches on their own machine, but this doesn’t mean that they can’t send that code back to some shared trunk when they finish something.
- The benefits to distributed version control do not end at the ‘coding while on a plane’ scenario. While this is indeed a benefit of distributed version control (while coding without network access you still have access to the complete revision history and can do commits), this is not the sole reason behind DVCS. You also get the benefit of reduced network overhead, making typical operations much faster, and you get a lot more flexibility in choosing a suitable workflow, and altering that workflow when it suits you. If you are working on your own pet feature but don’t want to check in your code to the main trunk until it’s done, you can still easily use revision control on your own little copy, and when it does come time to check in and merge all your changes to the trunk all the little revisions you made when you were working on it separately are preserved. This requires no setting up on the central server – any developer can create their own little parallel branch for a while, then merge it back up – it can be as simple as doing a ‘local commit’ instead of a ‘commit’ or ‘check-in’ (for me, that’s just one checkbox). Merging may sound complicated, but it’s not – it simply works. The system is smart enough to figure out which file was which and you can’t really break it – anything is reversible.
- Not all DVCS are git, or particularly like git. Git originated as a special-purpose version control system which Linus Torvalds developed to support his own personal workflow, managing the Linux kernel. While it now has pretty much all the features of a full-featured version control system, it still has its origins as a tool built especially for one person’s own workflow. Undoubtedly it is a good system, but if you try git and don’t like it, you should not assume that other distributed version control systems are the same as it. Git also has problems on Windows (a native Msys version is still being developed as of this blog post).
My version control system of choice at the moment is Bazaar, chosen because I need both Windows and Linux capability and I like that it is easy to use. There is not much separating it from Mercurial except for some small, almost philosophical conventions. Just as one almost insignificant example, Bazaar versions directories, allowing empty directories to be significant. I’d recommend either. Bazaar has the massive support of Canonical (of Ubuntu fame) and big projects such as MySQL. Mercurial has big projects such as Mozilla (of Firefox fame). You can get near instant help for either by going to their respective freenode IRC channels or by asking a question on Stack Overflow.
- If you are interested, try out this “Bazaar in five minutes” tutorial. Longer tutorials often give the impression that distributed version control is more complicated than it really is.