Re: Preventing "Dirty" Checkins

[Todd Denniston]

Ones Self wrote:
> 
> Hi,
> 
> I'm running a CVS server which compiles and tests the current
> files in CVS every hour.  I would like to make new checkins
> available _only_ if they compile and pass the tests.
> 
> So, if a user checks in something which does not compile, for
> example, other users who check out at that time will not get
> the new version until the problem is fixed.  Everytime you
> do an update, you know you're getting a clean version of the
> source; one that compiles, and in which the tests pass.
> 
you probably want to look into commitinfo in the Administrative files section
of the manual

Administrative files
https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC158

The commit support files 
https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC167

commitinfo
https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC169

instead of preventing checkouts, it prevents check in "If the command (or
script) returns a non-zero exit status the commit will be aborted."

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', but
you can choose the implementation level that is right for you. This way only
acceptable things make it in the base line.

<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>, but you may implement what ever mechanisms make you or your
boss happy.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter