Re: Preventing "Dirty" Checkins

[Pierre Asselin]

Ones Self <address@hidden> wrote:

> 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.

I don't think you can do that.  Well, you could trigger a full
recompile from commitinfo and allow the commit only if the build
succeeds, but your commits would be a bit sluggish that way.

What you *could* do is trigger the build from loginfo (post-commit)
and update a moving tag if the build is successful.  That way
your trunk can contain garbage, but the last successfully built
commit will have an unambiguous marker on it.  Your users can
choose the unstable tip,
    cvs checkout foo

or the last known good version,
    cvs checkout -rLAST_GOOD foo

but in the latter case they won't be able to commit changes.
(Well, they could start a branch, but that's taking us off-topic.)

The loginfo trigger would be asynchronous, as in
https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175
and there would be negligible delay to a commit.

Simple question:  why can't the developers do a top-level "make test"
before committing, and sidestep the question ?  Or do the unit tests
take that long to run ?  If the latter, you'll have to guard your
build-test-retag script against multiple instances of itself.

-- 
pa at panix dot com