Back to the buildfarm+git future

At long last I have today returned to the task of getting the buildfarm to work with git. Actually, refactoring the code to remove most of the CVS-specific code from the main line is the big task in this. I don't want to have the code littered with code that tests the SCM type and takes action accordingly. Instead we'll have an scm object initialised with the right SCM type and method calls on the object. Once that is in place and working for CVS, implementing a new SCM object type for git will be comparatively simple. Unfortunately, the CVS-sprcific code is scattered all around, so it's proving to be a non-trivial task to hack it out.

On a related note, I'm a bit concerned that every git repo clone carries a copy of the whole base repo in it. That means that each repo copy comes in around 234Mb right now, as opposed to 80Mb for a current checkout of the CVS HEAD branch. Now I have four buildfarm animals regularly building some 15 branches, so that adds up to around 3.5Gb of disk space, nearly a 300% increase. I have it available, but that's a heck of a requirement. I'm certainly going to run those members against a local mirror of the repository, just as I do now with CVS.

I actually keep many more trees than this. I have a directory where I do development and committer work, and in there I have a pristine checkout of each stable branch that is alive, plus HEAD. For any non-trivial changes I create a copy of the relevant tree to work in. The reason for this is I'm often working on more than one thing at a time, and just cd'ing to the relevant directory makes switching from one task to another very easy. But if the trees become four times as big, that might start to become a bit impractical, and instead I'll have to start setting up my own local git branches. No doubt it's the way things are meant to be done, but it will take a bit of getting used to for me.