Re: Developer branches

[Gianni Mariani]

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
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs