[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preventing "Dirty" Checkins
From: |
Paul Sander |
Subject: |
Re: Preventing "Dirty" Checkins |
Date: |
Tue, 28 Sep 2004 13:07:50 -0700 |
>--- Forwarded mail from address@hidden
>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.
Seems like the triggers and build procedures could conspire to enforce
a policy that developers complete successful builds, too. The build
procedure could have a target that lists its products, one of which
be a summary report. The trigger could audit the summary and make sure
that the targets are all newer than the sources and fail if anything was
done out of order.
>--- End of forwarded message from address@hidden