[IMP-dev] Git and IMP and more frequent releases

[Daniel Russel <>]

At the imp-dev meeting yesterday, the question of switching to git from svn was raised. The hope is that it would facilitate having more frequent mini-releases of IMP (monthly being a target) as it makes it much easier to maintain parallel development threads. The main advantage of git over svn is that it makes it very easy to make and maintain branches since one can merge branches repeatedly without problems. As an illustration, someone who is making a major change to a module that would take a while to implement could create a new branch in the repository for the change, lets call it distance_functions. While distance_functions is being developed, any changes made to the IMP main branch can be easy pulled into the distance_functions branch simply by doing "git rebase" (doing this is very painful with svn) allowing the two to keep in better sync. And when the change is done, it can be brought back into the main development trunk without complication (and done more than once if so desired).

This change would also makes dealing with releases much simpler as a release simply means pulling changes from the main development trunk into a release branch and adding a tag. Any fixes we want to make to release can be easily done in a hotfix branch and then directly brought into both the release and the main development trunk, rather than having to be manually pulled into both places as with svn.

At the meeting, a reasonably fraction of the people were already using git for other projects (and I'm using it instead of svn for accessing IMP). So learning it does not seem to be an insurmountable hurdlw

I would also suggest we check out git flow. It defines a standard branch structure that supports releases, hotfixes to releases, feature development branches etc and provides scripts to aid in doing basic tasks. It is available on home brew, but there does not seem to be a standard rpm for fedora. Boost appears to be moving towards using it, among other projects.

We can provide some kind of support for existing svn users (probably read-only). This may simply involve using git-svn to sync to the git head and push it to the existing svn repository.