One of the blogs I keep tabs on is Eric Sink, and his latest article Obstacles to an enterprise DVCS struck a chord. I was also interested in Martin Fowler’s somewhat related take: http://www.martinfowler.com/bliki/VersionControlTools.html
I personally think that the rise of DVCS (Distributed Version Control Systems just in case you’re wondering) such as Git and Mercurial is a really good thing. As Martin mentions, the value of GitHub and BitBucket show their project collaboration features.
I am quite happy for a bit of controversy to arise (Linus on “Subversion is Brain Dead!”) as it proves that the subject is important, and worth learning about (Oscar Wilde’s dictum “The only thing worse than being talked about is not being talked about”).
One of the points made by Martin is about the importance of process and making sure you are using your tool sensibly – he mentions ThoughtWorks teams using local VCS on a daily basis and checking in to the corporate standard one a week or so at times.
The advantages of a DVCS:
- the ability to work easily remotely (”on a plane” etc)
- lightweight branches and excellent merging capabilities – often rather better than centralised systems
- day to day performance – because it’s local is typically very good
- distributed repositories make backup less of an issue
However, I think there are challenges to using DVCSs in corporate environments:
- centralised systems are easier to control – not always a bad word! You may want only certain people to be able to view or update certain files (as an example I have done some consultancy for Camelot Group who run the UK National Lottery – as you can imagine, the audit requirements are fairly high. I have seen the names of modules called things like NotifyWinner.java – starts certain creative processes going in the mind!).
- the visibility and communication of status – if checkins or branches are made on a central system then they are typically visible to other people, and can be tracked and reviewed, and if necessary chased up. Where is the “master copy” of code, or a particular release?
- security of your assets – what happens if your whole code base on a cloned repository on someone’s laptop goes walkabout? Encryption can address some of this, but it is still a danger.
Some of these can be addressed by working practices, but the nature of DVCSs mean you have to be careful. For example, there is typically a “master repository” for open source projects, updating of which is restricted to a few people.
The fit of DVCSs to open source development is easy to see – anyone can clone a repository and make changes, and those changes can be fed back and committed in a controlled manner (much better than sending patches).
However, I was interested to see the lament by James Bennet, Django’s release manager, mentioning the difficulties of tracking and coordinating development across larger numbers of developers, repositories and workflows: http://www.b-list.org/weblog/2010/feb/02/branching/ (see his lightning talk at Pycon). As he mentions: “in Django 1.1 there was a feature scheduled for this release, but he lost track of it, and they slipped by a month).