Pete/Piet Delaney wrote:
quoted text
> -----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.

quoted text
> 
>> 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.

quoted text
> 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).

quoted text
>> 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 ;-)

quoted text
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html