Adopting a DVCS across an entire organization could be an expensive and disruptive process. However strong teams may be able to realise benefits from adopting a DVCS like Mercurial or Git. Fortunately these tools can be used in a way that is complementary to existing source control systems. In this way many of the benefits of using a DVCS can be realized without major investments in training and infrastructure.
In recent years the open source community has rapidly adopted Distributed Version Control Systems (DVCS), in particular Git and Mercurial (sometimes called 'Hg' after its command line). Java, the Linux kernel, Ruby and Rails have all adopted distributed version control systems, proving their applicability in large distributed teams.
Many ThoughtWorks developers prefer using DVCSs since they allow more flexible workflows. Cheap branching means that it is very simple to create a branch for an experiment, or to stash away partly done work while working on a bug for the current production version. There are many advantages to a DVCS, for a more thorough description of this see Martin Fowler's "Version Control Tools" .
A DVCS can also be much faster when working in a distributed team, since the entire repository is local, and checkins don't need to be pushed to the central repository. This also enables working offline, which is important if teams are working in situations where network connectivity is poor. This could be because the developer is in a country with poor infrastructure, or simple that the developer is in a hotel or sitting in a cafe or a bus with only slow 3G connectivity.
Enterprises have been somewhat slower in adopting these new tools. Often there is a large investment in training staff and building SCM infrastructure which means that a wholesale change to use the new tools would be expensive and disruptive. However it is possible to gain many of the benefits of a DVCS while maintaining current infrastructure.
Using a DVCS with a legacy VCS
Most version control systems maintain their change metadata inside special directories. For example, CVS puts a CVS directory in every versioned directory. SVN creates a .svn directory in every versioned directory. Git and Mercurial version whole directory trees. There will be a single .hg or .git directory at the root of the tree. Also, these systems allow you to specify that particular files or directories should be ignored.
To use a DVCS with a legacy VCS you first check out the code from the legacy VCS. Let's suppose you want to use Mercurial as your DVCS. You initialize a Mercurial repository in the same directory and add all the files from the working copy. Your directory is now version controlled by both Mercurial and the legacy VCS. You can start working in that directory, and checking changes into the local Mercurial repository. When the time comes to update the legacy VCS, you simply checkin the same way you always have. New and changed files since your last checkout will show up as changed, and be checked in correctly. Similarly when the central repository changes, checkout the new changes and check them into the local Mercurial repository.
We have used to provide a buffer to tools that are complex or make our preferred way of working overly painful. For example a common practice when teams are working with Clearcase is that the teams will maintain a mirror of the clearcase code in a local repository. All code is developed against this repository, and at regular intervals the changes are pushed to clearcase.
Using git with an SVN repository (git-svn)
Git provides support for maintaining a local git repository that interoperates with a remote SVN repository via a set of commands known as git-svn. Using this tool, developers can realize the benefits of using git, while leveraging existing SVN infrastructure. There are no changes required to the existing SVN repositories to enable this approach. All changes from the svn repository are mirrored locally, and all changes in the git repository can be committed to the SVN repository, meaning that the full history is preserved in both repositories.
Within ThoughtWorks we have seen a very rapid uptake of this approach. In fact, a recent internal survey of our developers found that there are more teams using git-svn than are using svn directly.
ThoughtWorks Studios tool support
Cruise is our continuous depoloyment tool. It is developed using Mercurial, and supports both Mercurial and Git (as well as Perforce and Subversion).
Mingle, our project management and collaboration tool is also developed on Mercurial. Mingle integrates with Mercurial (as well as Perforce and Subversion) so you can see which changes are associated with a particular story.
- Git home page - http://git-scm.com/
- git tutorial - http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
- git-svn Manual Page - http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
- git-svn Crash Course - http://git.or.cz/course/svn.html
- Mercurial home page - http://mercurial.selenic.com/
- Mercurial manual "Mercurial: The Definitive Guide" - http://hgbook.red-bean.com/
1. Martin Fowler, Version Control Tools - http://martinfowler.com/bliki/VersionControlTools.html
Please sign in to leave a comment.