>--- Forwarded mail from [EMAIL PROTECTED] >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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
