Early experiences transitioning from Perforce to Git at ECMWF

Francesco Pierfederici & Paul Burton European Centre for Medium-Range Weather Forecasts, Reading, UK.

Transitioning a large code-base from one source control system to another is often times technically simple. What might not be as simple is getting developers to successfully adapt to the new ways of working. Different systems manage source code, commits, branching and merging sometimes very differently. Of course, cases where the old system is philosophically similar to the new, the transition is simple, such as a transition from CVS to SVN.

ECMWF’s previous transition from Clearcase to Perforce was made easier for users by encapsulating Perforce commands in a wrapper script which enabled existing working practises to be broadly unchanged. Although this made life easier for users, it did mean that Perforce was used in a less than efficient manner, in order to attempt to mimic Clearcase’s behaviour.

A more complex transition is more, well, complex. This is the case with our transition from a centralized version control system (Perforce)1 to a distributed version control system (Git).

Code-wise, we made the decision of importing into Git only the head of the Perforce repository, leaving all user branches behind2. The reason behind this decision was that we had a very large number of user branches, the vast majority of which were not actively developed any more, having being merged into head a long time ago. Importing Perforce head into our Git master branch was a painless process, enabled by the git-p4 client command.

A nice side-effect of the import process is that all repository history and all commit messages are preserved. Also, one can choose how much of this history to import into Git, which for large, long- running projects can be significant. One issue to be aware of is that all Git local clones of the main repository carry the complete history with them. Consequently, cloning a large repository can take quite some time. For this reason, we decided to split the repository history into two trunks; one that every developer clones and that includes only a small number of supported versions of our software, the other trunk holds the remaining history and is only preserved for historical reference.

A potential stumbling block for many of our developers in the transition is the Git concept of a two- phase commit. In Perforce, as well as in many version control systems, there is no distinction between local commits and remote commits: all commits happen on the server. In Git a local commit is just local and does not affect code on the server. For this reason, a commit in Git needs to be followed by a push, which for novices is easy to forget.

Another significant difference between Perforce and Git working practices is branching and merging. Branches in Perforce have tended to be large and permanent (we do not allow users to remove branches from the repository under normal circumstances), whilst in Git, branching is quick and

1 Although Perforce can be used in a distributed fashion this is not the way it is used at ECMWF.

2 Tools are available to allow users to import any branches they need. easily reversible – this encourage a different style of working with smaller more transient branches which are regularly merged into a main development version of the code. This is a significant departure from the way we currently work where any given developer would work on their branch in complete isolation for potentially may weeks before the long and often painful merge process onto the main branch.

Summarizing, the transition from one version control system to another is usually rooted in sociological reasons and usually the main difficulties in the transition are sociological. Our experience has been no different.