RE: Versioning between checkout|update, commit

[Hugh Sasse Staff Elec Eng]

On Thu, 1 Apr 2004, Paul Sander wrote:

> >--- 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 [of breakage.]
>
> >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.

Thank you, I'll look at that.
>
> >> --- Forwarded mail from sharpd(.--.-.)cisco.com
> >>
> >> Create your own private branch to do work on.  When you want to save
        [...]
> >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.

OK, thanks.
>
> 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.

I'd agree with that, too.
>
> >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.

I'm still a bit confused about -j, (which is off topic for this
thread), I think for the same cognitive reasons that people produce
reverse patches by mistake -- working correctly from (multiple)
differences is tricky.  I think I'll need to play with that a bit,
but if there are any slow, gentle tutorials on this aspect of
cvs usage I'd be grateful to know about them :-) .

>
        Thank you,
        Hugh