Distributed Version Control – Bridging the Gap to the Enterprise
Posted on Tuesday, November 3rd, 2009 | Filed under alm, git, mercurial, subversion
I’ve been spending a lot of time reading about and playing with distributed version control tools (DSCM) recently, particularly Git and Mercurial, which seem to be the two primary players in this space at the moment.
While Git certainly has its followers (Android being a prominent one), Mercurial offers pretty much the same range of features, in a much more user-friendly package. The latter got a shot in the arm with Google Code announcing their support for it earlier this year.
What I’ve been asking myself is: will this technology work in the enterprise?
There are a number of obvious concerns, which are closely tied to the stated advantages of DSCMs:
- There is no server / Everyone is their own server. Companies rely on the centralized repository concept to manage backups. The model ensures that anything that is committed to version control, lives in a safe place, and is accessible to all those who need and have appropriate permission. While DSCMs allow for the creation of de facto servers, and processes can be defined to enforce some measure of good order, any such scheme relies almost exclusively on individual cooperation, and tools offer little or no help by way of auditing compliance. In many ways, a DSCM’s greatest strength is its greatest weakness.
- What doesn’t exist, can’t be secured. Without a centralized server that everyone is forced to read from and write to, how can fine-grained access control (particularly read access) be implemented? The current crop of tools doesn’t cater to this at all: every user essentially has read/write access to anything they can get their hands on. Only when pushing your changes to another user or ’server’ you may encounter write restrictions. This is going to be an instant deal breaker for a lot of organizations. Someone needs to come up with a solution to this problem for DSCMs to gain broad commercial appeal the way Subversion has.
- Who’s working on what, where and how do I get my hands on it? If development is distributed, how is this then reconciled with a presumably centralized ALM (Application Life cycle Management, i.e. task/issue/defect/project/requirements management) solution? For development to be truly distributed, developers need a distributed ALM solution as well. How this looks in practice or even conceptually, now that’s where someone is going to make a name for themselves.
Comments
One Response to “Distributed Version Control – Bridging the Gap to the Enterprise”
Leave a Reply
Distributed Version Control – Bridging the Gap to the Enterprise http://tinyurl.com/yfdmlsg (via @rvanoo) good piece Rob.