[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:01:48 -0700 |
>--- Forwarded mail from address@hidden
>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.
>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.
Yet another method is to divorce the notion of "latest checked in" from
"eligible for build". I personally would never discourage anyone from
checking in their work, and I found that providing a handoff method in
which the user explicitly guarantees that the code will build is a useful
tool. Collecting up the bits for inclusion (or exclusion) in the next
build is a simple form of change control that also improves the quality
of the builds overall because changes can be undone (sometimes
automatically!) under error conditions.
>--- End of forwarded message from address@hidden