RE: Preventing "Dirty" Checkins

[Jim.Hyslop]

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)