Sean Moss-Pultz wrote:
> They say to give everyone their own "sandbox",
> by making a branch for each user
This is the "private branch" approach. It is a more general case
of "task branch". A private branch can last for the duration
of many (sequentially executed) change-tasks by a developer.
It is a very commonly used 'pattern' that allows private checkpoints
(a.k.a. "Private Versions" in the SCM patterns book) to capture
intermediate milestones of in-progress change-tasks that would
destabilize the codeline if committed at that time.
> and then one admin merges all the changes back to the trunk
This is the part that sounds very un-CVS-like. It is commonly
called "pull integration" or the "integrator-pull" model. It
is very common in larger teams and projects.
I don't recommend it for smaller teams and projects. I prefer
the developer-push model (developers merge their own changes
to the trunk) whenever and wherever feasible.
Pull-integration often contributes to (and even creates)
an adversarial "throw it over the wall" situation between
developers and integrators. It can also impose a lot of
additional (and usually avoidable) friction on development.
Sometimes that additonal friction is necessary to stop things
from being too chaotic and uncoordinated (particularly in complex
systems where communication and coordination must span multiple
teams and sites/locations/components/subsystems). But most of
the time (especially in smaller projects that are less than
a million lines of code and teams of a dozen or less people)
I beleive a shop is better suited by developer-push model.
I have some slides on how a branch that I call a "Docking Line"
can be used to balance the push-versus-pull tension. And in
the SCM patterns book, the "Active Development Line" is basically
a "docking line" for the "Release Line".
The slides are part of some ClearCase-specific presentations
at RUC2000 and 2002 but the majority of the content is not
too specific to ClearCase and very easily applies to Subversion
and Perforce and many other VC tools. You can download them from
http://acme.bradapp.net/#ClearCase
(see the last two bulleted items)
A much more general (and much larger) paper on branching best
practices and pitfalls can be found at
http://acme.bradapp.net/branching
(A section or two discusses the "Integration Wall" pitfall and its
remedies and prevention).
--
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
Received on Wed Jan 7 19:58:15 2004