RE: Versioning between checkout|update, commit

[Paul Sander]

>--- Forwarded mail from address@hidden

>Thank you for the responses...
>On Wed, 31 Mar 2004, Paul Sander wrote:

>> 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...

And some places do it successfully while mixing active development
and baseline integrations solely on the trunk.  Search the info-cvs
archives for "submit/assemble" for details.

>> --- Forwarded mail from sharpd(.--.-.)cisco.com
>>
>> Create your own private branch to do work on.  When you want to save
>> work, commit the code.
>> When you are done, merge the changes down.

>The book "Open Source Development with CVS" says that you should
>keep few branches active at any one time.  I'm wondering if there
>are penalties (apart from storage costs) when many contributors
>create their own branches?

>From a system point of view, I don't believe there's any technical
basis for such a statement.  From a human standpoint, you want to limit
the number of branches that any single user accesses.  The typical
user should try to limit their exposure to an integration branch and
maybe one or two personal or feature branches.  However, you can have
hundreds of users, each with their own personal branches.

Another rule of thumb is to try to keep your branch structure as
shallow as possible.  Again with CVS, I don't believe that there's
a technical reason to do so, but it's harder for the humans to
track them if they're deeper than about 3 or 4 levels.

>Also, doesn't having a separate branch for your own development make
>doing an update in between edits more difficult?

You need to specify a couple of -j options to the update command and
tag the result of every merge.  That's pretty standard.

>> Other possibilities include implementing a backup system that takes
>> hourly snapshots....

>Yes, but it would be less flexible than SCCS, I think...
>>
>> --- End of forwarded message from sharpd(.--.-.)cisco.com

>--- End of forwarded message from address@hidden