[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Preventing "Dirty" Checkins

From: Jim.Hyslop
Subject: RE: Preventing "Dirty" Checkins
Date: Wed, 29 Sep 2004 09:31:05 -0400

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. (
Columnist, C/C++ Users Journal (

reply via email to

[Prev in Thread] Current Thread [Next in Thread]