Over the past week, one of our engineers has been migrating our entire Version Control System (VCS) from a Subversion backend to a Git backend. We will be updating the website and our documentation to change the links and references from Subversion to Git. Please bear with us as we go through this, as there will undoubtedly be some broken links during the interim.

Effect on end users

For end users, this change won't have any direct effect. However, it will produce an indirect benefit for our end users because it gives us a lot more flexibility with release scheduling.

Our current release management process involves identifying the most critical changes that need to go into a particular version, determining the schedule for each of those changes, and then setting the release date based on the longest schedule. For example, in release 2.8, let's say that we have 3 major features to deliver as well as 10 minor improvements. The three major features are expected to take 2 weeks, 4 weeks, and 6 weeks, respectively. Therefore, we will set the release date at 6 weeks from now. At the end of 6 weeks, we should have finished all of the major tasks and whatever improvements we had time to squeeze in, and we'll be ready to release.

But if the 6 week effort runs long -- complications arise and now it takes 10 weeks -- then the entire release is delayed by 4 extra weeks while we wait for that one effort to be completed. In the meantime, we can't begin work on any new features, because those features could also spiral out of control and delay the release even further.

With git, however, each long-running development effort can be performed on a separate branch. Branches are independent work streams that allow each developer to develop a single feature in isolation and then merge their work later with other developers. Branches are possible in Subversion, and we used them to separate release-quality code from development code. However, merging separate branches in Subversion was quite a headache, and for that reason we kept branching to a minimum.

Git provides us with extremely fast and easy merging, so we will be able to use branches far more effectively. The net result is that we will able to schedule releases on a fixed timeframe, say every 6 weeks, and when it is time to release we can pull in features from all the branches that are complete and we can leave out the features that incomplete. Incomplete features will no longer present a bottleneck for our development timeline.

Effect on developers

For developers and technical users who are following project updates directly in the VCS, however, this will directly affect the way you obtain source code.

Instead of checking out source code using a subversion client, developers will need to use a Git client and access it at http://git.openfisma.org. You can also browse the code at that same address.

Git is a more complicated VCS than subversion, so if you are new to it, read through a Git tutorial before you dive in.

We'll be updating our Development SOP document soon with more details on how the workflow will be built around Git.