>--- Forwarded mail from [EMAIL PROTECTED] >The problem with this methodology is that it's very easy for stuff to >get checked in that will break the build for other people.
This is only true if there's an assumption that latest is greatest. Shops that don't equate the latest checked-in work with candidates for integration don't subscribe to that, by definition. If you're worried about people's development environments breaking as a result of doing a "cvs update" then there are several ways to handle it. One is to use floating sticky tags. Another is to partition the source code so that ownership has clear boundaries. > Isolation is >*good*. Allowing people to save work that may not be finished is also >good( although maybe not as good ). I would never, *ever* discourage anyone from committing their work... >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Andy >Jones >Sent: Thursday, April 01, 2004 10:05 AM >To: Hugh Sasse Staff Elec Eng; [EMAIL PROTECTED] >Subject: RE: Versioning between checkout|update, commit >>> Some shops also implement a handoff mechanism that divorces the >>> notion of "latest committed" from "candidate for integration". That >>> allows the developers to commit with impunity without fear that the >>> world would see something inappropriately. >> >>Yes, some places seem to do this with different branches... >You don't *have* to use branches. >Here we tag each release. We also tag the *next* release, and this tag >gets moved and updated as part of the testing process. >The developers are free to commit code at any time they like, knowing >that it will only appear in the test environment once the release tag >has been moved to that version. >The only time they would need to make a branch would be if they were >developing something that clashed with other development work. However >this is handled, it will still need a merge at some point - the problem >is not CVS, but the work itself. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
