Re: "Floating" tags and automating the build process

Weintraub, David wrote:

> In the stable head model, all developers develop off of a private branch
> and not off of the head of the main branch.
[... snip ...]
> Either that, or have a "build" branch and let the developers work off of
> the trunk. Then, when they finish, they can merge onto the build branch.

This is the pattern pair known as "Active Development Line" and "Release
Line" from the SCM Patterns book (www.scmpatterns.com). Development has
their own codeline for integration and they use the tip. The formal
CM/Build/Integration group has their own codeline to which the
merge+build only "good/stable" stuff.

The "Streamed Lines" paper (acme.bradapp.net/branching) describes this
relationship between codelines with a single pattern it calls "change
docking line" but the basic idea is the same.

The strategy/reason for splitting into two branches here follows the
advice of "branch on incompatible policy" from Wingerd+Seiwald's 1998
paper on "High-Level Best Practices in SCM"
(http://www.perforce.com/perforce/bestpractices.html)

I have seen this implemented with workspaces as well as with branches.
Ive sometimes seen this called a "green-light / yellow-light" approach
or a "gold and silver" approach, where the more stable
workspace/codeline is the "gold" or "green" and the more volatile/risky
one is the "silver" or "yellow". Ive also seen it extended to three
risk-based options instead of two, called any and all of the following:
red>yellow>green, silver>gold>platinum, fast>moderate>slow,
run>walk>crawl & solid>liquid>gas :-)

-- 
Brad Appleton <brad@bradapp.net> www.bradapp.net
    Software CM Patterns (www.scmpatterns.com)
    Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org