Pete/Piet Delaney wrote:
-----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.
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).
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@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
