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