Scientists, start using distributed version control

[bascule]

Do you work in scientific computing? Does this sound like your development process:

 

You use a program / model maintained by a central group. They release new versions every now and then. Sometimes you make improvements directly to the central codebase and submit patches.

 

You take their releases and start wiring in your own code or 3rd party modules. In the case of 3rd party modules, you're also making your own improvements, possibly to make the code easier to integrate into other projects, and maybe want to contribute that back.

 

You may also have many scientists in your group who are working on specific modules. This may take the form of one or two scientists / programmers working on a specific module. Once the module has been integrated, you then want to tie two different branches, which each add one module, together so you end up with a new branch that incorporates both modules.

 

This more or less describes the workflow at my previous scientific computing job. All of this was horrible pain too. Whenever a new version of the "main" model came out, people either 1) spent weeks trying to upgrade their code or 2) gave up and didn't bother upgrading.

 

Tying two branches with two different modules back together was also pain, since there were often incompatible code changes to the main model that were hard to merge.

 

Distributed version control systems, such as git, are perfect for this sort of development. Git makes branching and merging much, much easier that other source control systems like CVS or Subversion.

 

Git perfectly fits the scientific computing workflow. It allows one person to make a branch which is their own, but that they can then share with other scientists, while still incorporating changes from the original model. It allows different groups to work on integrating different modules simultaneously, then makes it much easier to merge everything into a single codebase when everyone is ready.

 

I'm using git on several projects (and actually use git as a Subversion client for projects I'm working on that use Subversion) and I wholeheartedly recommend it.