Re: Commitinfo question

[Dennis Jones]

Why not build on a nightly basis, instead of on a file-commit basis?
Compiling on every commit seems like tremendous overkill to me, not to
mention the possible performance degredation of the CVS server while it is
compiling your source code.  And multiple developers could commit files
simultaneously, which might cause multiple compiles to be executing at the
same time.  That could cause a real, serious drag on system performance.

I highly recommend that you create a script that runs nightly, at a time
when most (if not all) of the developers have gone home for the day.  The
script would check out all the source code and build everything from
scratch, and the script could run on any machine that has the appropriate
compiler(s).

Doing your builds on a nightly basis has several advantages.  First, it is
possible that someone will check in only one or two files that are part of a
larger change, where several (or many) files would be required for the
entire change to be in effect.  If you try to build as soon as the first
file or first few files have been checked in, it is very likely that the
build will fail, and that build would have been a waste of time because you
knew it was probably going to fail.  On the other hand, if the developer
takes several hours to commit all of his/her changes -- no problem -- as
long as all the changes are committed by the time the nightly build kicks
off at whatever time you choose, the build should succeed.

Second, by building everything from scratch, you stand a much better chance
of catching errors in the code, not only at build time, but also the next
day when you have a full build of all of your applications ready for tesing
by your QA person(s).  Of course, if you have an automated test system, it
can also be kicked off by the script to test the programs, right after the
build finishes.  Then, when you come in the next morning, everything has
been built, tested, and ready for QA.  If there were any errors in the
build, have the script send an email to all the developers with a log of the
compiler's error messages.  The person who broke the build will probably
recognize the errors he/she made and realize that he/she forgot to check
something in, or knows exactly what to do to fix the build.  Then, that
night, the build should succeed (unless he, or someone else, has made
another mistake!).

And third, at night, it is less likely that anyone will be checking in any
code changes, so the machine will be free to compile and test your code
without having to do double duty both compiling and serving up developers'
CVS requests.  This will undoubtedly save your developers lots of
frustration during the day.

This process can help to make your development organization much more
streamlined.  I hope this helps answer your question, or at least gives you
some ideas.

- Dennis

----- Original Message -----
From: "Ryan Hennig" <address@hidden>
To: <address@hidden>
Sent: Monday, October 23, 2000 6:56 PM
Subject: Commitinfo question


> Hello,
>
> I am currently setting up an automated build and testing system that rides
> on top of CVS, using the commitinfo file to run compilations and tests on
> each commit.  I was just wondering if anyone on this list who has done
this
> type of thing could share some wisdom with me.
>
> I am particularly interested in the following:
> - What kind of problems did you run into early on?
> - How was your system designed (generally)?
> - Did you run compilations and/or tests on the same box as the CVS server,
> or did you send the files off to another box (this is what I am trying to
> do)?
> - Is there a better way to do this besides using commitinfo?
>
> Any other input would be GREATLY appreciated.
>
> Thanks,
>
> Ryan Hennig
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs