Todd Denniston wrote: > you probably want to look into commitinfo in the > Administrative files section > of the manual [...]
> make your command (or script) build the software and if it > fails return > nonuser. Checkin's will take a long time if you force 'make > clean world', In my case, "a long time" would be several hours ;=) One catch I can see with this approach is the platform. For example, our development platform is Windows using Microsoft Visual Studio, and our repository is on a Solaris machine. Despite all my writing about portable code (see URL in .sig) much of our code is extremely MSVC-centric. > <opinion>The better method would be to hire engineers who > understand the > process of making good checkins, and/or use a process that > involves the > engineer doing the check before committing and dock his/her > pay for bad > commits<\opinion> I agree - that is by far the better approach. In our shop, we rarely have broken builds. We have an automated build that runs once a day, and emails every member of the team the build results in summary form, with a link to the full build log. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
