Re: Qgit performance and maintain CVS environment with GIT repository

From: Andreas Ericsson <ae@op5.se>
Date: Oct 19, 2007, 09:52 UTC
Message-ID: <47187E4E.50006@op5.se>
In-Reply-To: <47187518.1090007@bluelane.com>

Pete/Piet Delaney wrote:

Show 34 quoted lines

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andreas Ericsson wrote:
>> Pete/Piet Delaney wrote:
>>> Johannes:
>>>   I read somewhere in the past week that it was possible to maintain
>>>   our existing CVS environment with git. I though it was a separate
>>>   package to export git back to cvs but I just noticed a git-cvsserver
>>>   and as a std part of git and was wondering about using that.
>>>
>>>   We have a number of build machines with flamebox perl scripts pulling
>>>   out CVS branches for builds. I was wondering what is the best way to
>>>   use git and it's nicer pull/push model and merge facility and possibly
>>>   maintain CVS exports for scripts doing builds if possible the cvsweb
>>>   and bonsai (CVS Query Form) that a number of engineers are currently
>>>   using. I started looking over out flamebox scripts with the intent
>>>   up converting them over to git but I mentioned the git to cvs
>>>   coexistence and we are wondering if that's a better route than
>>>   upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>>>   and gitweb along with the git utilities seems at least desirable.
>>>   Any thoughts or suggestions?
>>>
>> If you do convert them to git, you can fairly easily do an automatic
>> bisect on build-errors, and the developer can (after some time) get
>> an email of what machines they broke the code on and what the bad
>> commit was.
> 
> Could you explain that a bit more. Sounds like you saying it's worth
> messing with the flamebox scripts to use git instead of using the git
> cvserver and letting them pull the cvs branches as they do now. Is the
> existing flamebox email of build log effected buy switching form cvs
> to git? I hadn't expect it to change.
>

git has quite a wonderful tool named git-bisect. In short, it helps track down what particular commit introduced a bug. Let's say your builds fail for some reason, and the build-scripts send out the build-log to the developer. The script can then continue to check the repo by running git bisect on it and finding the commit that introduced the build-error, and email that too to the developer. In short, when you check things in at 5 o'clock that doesn't build, you don't have to sit there and wrestle with it. You can go home, have dinner, tuck the kids into bed, and then open your mailbox and have an email with the exact commit that introduced the regression.

Now, if you can also convince your developers to make small and isolated commits, and your build-system is such that it doesn't rebuild *everything*, but has proper dependency tracking and suchlike (a properly written Makefile for example), the developer will get pointed to a commit that affects perhaps 10-20 lines of code within a reasonable time, and it should be so trivial to fix that anyone can do it.

Show 11 quoted lines

> 
>> Besides that, it's not a black-and-white scenario. If I were you I'd set
>> up git-cvsserver and make sure that works for all the scripts, and then
>> pick one or two auto-build things to convert to git. Preferrably on a
>> separate machine, so everything keeps working the same as always while
>> you're fiddling with the auto-build stuff.
> 
> I get the impression your suggestion to first get git-cvsserver serving
> the repo so that the build machines works without any change and then to
> go to each build machine and update the scripts to use git instead of cvs.
>

That's the idea, yes.

> Are there any tricks I need to so on the repo to make the branches pull
> out with exactly the same commands that we are currently using. My guess
> is that the branch checkouts should work without any messing around.

I'm not sure what you mean by that. You can tell git to automatically fetch any new branches (that's the default, I think), but you'll ofcourse have to switch to using git-pull instead of cvs co (or whatever you're using now), unless you use git-cvsserver. AFAIK, git-cvsserver mimics a cvs server well enough that it accepts all commands and the two are interchangeable (assuming the background repo conversion has been done, ofcourse).

Show 5 quoted lines

>> Just my two cents.
> 
> Hey, you two cents could easily save me hours of messing getting this
> conversion done.
>

That's well-invested money then ;-)

> BTW, I don't think anyone is checking into the repo, but if they do
> can I do another git-cvsimport to just update the one I already did?

Yes. It works incrementally, but since cvs commits aren't atomic, you have to wait 10 minutes after the cvs commit *starts* to be able to use cvsimport to move it over to git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231