[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Developer branches
From: |
Paul Sander |
Subject: |
Re: Developer branches |
Date: |
Sat, 2 Feb 2002 11:02:35 -0800 |
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