Re: Developer branches

[Paul Sander]

If someone is making huge, disruptive changes to the project, then it
certainly is best to spawn a branch and bite the bullet with a nasty merge.
Or, better yet, spawn a branch for continuing work and put the disruptive
change on HEAD; that way you can control the depth of your branches if
there are a lot of such changes coming.

On the other hand, divorcing the "eligible for build" concept from the
HEAD is also a huge win, because then you begin to enable an environment
that assures a 100% success rate for the nightly builds.  The reason for
this is because employing a better change control method provides better
immunity from garbage commits that tend to happen at the last minute.

--- Forwarded mail from address@hidden

I've found that is you plan to make a 'disturbing' change, it's best to 
do that in a branch - get it working and merge it in.  The idea is that 
the HEAD branch *must* always build (at least after a short period 
(hours max) of instability).  So multiple dev branches for big 
collaborative changes is the method that seems to work best for me.



Paul Sander wrote:

>Another approach that doesn't require developers to perform as many merges
>is to implement a hand-off procedure that declares certain versions as
>eligible for the build.  This can be as simple as applying tags, or it could
>be more complicated.  That way, the developers and the builders can share
>the same branch and yet still have some recourse if someone commits garbage.
>
>Check the info-cvs archives for "submit/assemble" for discussion of one
>successful method that doesn't rely on tags.
>
>--- Forwarded mail from address@hidden
>
>We are using CVS to store Java source code.  Currently, all developers in
>the project are directly commiting against HEAD.  We would like (as much as
>possible) to keep HEAD in a stable state and so would like to start using
>branches to create a dev environment.
>
>Is this better approached by creating a single DEV branch or creating
>seperate dev branches for each individual developer?  What are people's
>experiences with either approach?
>
>--- End of forwarded message from address@hidden

--- End of forwarded message from address@hidden