[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
>Jones
>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