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 [EMAIL PROTECTED] > >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 [EMAIL PROTECTED] > > >_______________________________________________ >Info-cvs mailing list >[EMAIL PROTECTED] >http://mail.gnu.org/mailman/listinfo/info-cvs > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
