This is sort of a follow-up on an earlier post that I had made: Life after Subversion.
I’ve been toying with the idea of moving from Subversion (a centralized version control system) to a Distributed Version Control System (DCVS) like Git, Mercurial or Bazaar for about 6 months. I played with Mercurial and Bazaar earlier this year and found that moving our development from Subversion to Mercurial or Bazaar was was a fairly significant change.
Over the last few weeks I’ve been looking again at Git. Obviously there are lots of advantages of using distributed version control system. However, what I found was that there are quite a few issues that I had to consider before making the jump from Subversion.
Before I talk about these considerations, here what what Wikipedia defines a DCVS is:
distributed revision control takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository with which clients synchronize, each peer’s working copy of the codebase is a bona fide repository. Synchronization is conducted by exchanging changesets, which define unique versions of every file, from peer to peer.
So here are the factors that I had to consider when thinking of moving to a distributed version control system.
I (and the team I work with) primarily use Eclipse for ColdFusion and Java development. There is excellent support for Subversion in Eclipse through two plugins, Subclipse and Subversive. My team mates who use Windows also use the TortoiseSVN extension.
Git lists an Eclipse-based plugin on its website. However, it is still in early stages of development. Mercurial has recently launched version 1 of its Eclipse-based plugin so that is a big brownie point for Mercurial.
But the point here being… IDE support for decentralized systems is still in it early stages.
The primary interface to work with a DCVS is command line. Now I know that developers should be comfortable with using command line. However, there are different types of developers. Also, at times development teams comprise of non-developer individuals like designers, coders, project managers, etc. To expect everyone to start using command line does not work out too well in a team situation.
Obviously the team has to get used to a new way of working with version control. And there is a considerable learning curve there. The larger and more diffused the team, the more of an issue this becomes.
Repository Hosting Infrastructure
Most distributed version control systems are *nix friendly. Although they have some form of Windows-based port, but those tend to be much slower than their *nix siblings. So if you are a development team that primarily uses Windows, you need to either live with the relatively slower performance of the version control system, or start looking at using Linux (which is a big jump for many in terms of skill sets etc.)
Integration with other Systems
In my current Subversion-based setup, there are other systems that are tied into version control. These include systems to create automated builds, repository viewers and code review systems. Moving to a DCVS would involve investing resources in upgrading these ancilliary systems as well. I’m not sure if there is an easy way hook these systems into a DCVS.
So in the end…
At this point, the time and resources required in moving to DCVS is a major issue. And that proves to be a too large an issue compared to the advantages that a DCVS offers — at least for the the team I work with and type of work we do.
On the whole, the longer you’ve been using Subversion (or any other centralized system) — and consequently the more team members are used to it and the more you have other systems hooked into it — the harder it will be to make the jump.