[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Versioning between checkout|update, commit

From: Paul Sander
Subject: RE: Versioning between checkout|update, commit
Date: Thu, 1 Apr 2004 07:20:02 -0800

>--- Forwarded mail from address@hidden

>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: address@hidden
>[mailto:address@hidden On Behalf Of Andy
>Sent: Thursday, April 01, 2004 10:05 AM
>To: Hugh Sasse Staff Elec Eng; address@hidden
>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 address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]