On Nov 26, 2007, at 7:59 AM, Ben Collins-Sussman wrote:
> Basic Merging (NEW)
>
> Merging branches to each other
> -> show how to repeatedly merge trunk to the example
> feature branch
> -> show how to merge feature branch to trunk when done
It seems to me that there are four kinds of "merges," and your outline
appears to discuss only two (not entirely sure which two, as it's only
an outline):
- merges during updates
- cherry-picking from one branch to another
- whole-branch merge (refresh a feature branch from trunk, and also
deliver the feature to trunk)
- vendor branching (a whole-branch special case, due to open-ended
persistency)
I think also that the "layman, to harry/sally/feature, to vendor"
development is very slow, and never reaches the full story of multiple
long-lived, interrelated branches -- which, I think, is the real
motivation for merge tracking, since simpler cases are still fairly
reasonably handled with manual revision specification. I suppose The
Book does have an obligation to explain the simple end of the spectrum
to the novice, but it also needs to help the poor sod trying to manage
a bigger problem.
A simple "poor-sod" example: in CollabNet, at this moment, we're
actively working
- branches/release/SCAST_4_5_1
- branches/release/SCAST_4_5_2
- branches/release/SCAST_5_0_0
We work 'em all because we have 'em all in the data center for various
customers. Changes to 4.5.1 are restricted to serious bugs ... i.e.,
we pretty much want to merge them all to 4.5.2, a clear need for merge
tracking. Changes to 4.5.2 are nearly as restricted, but perhaps not
quite as rigidly so. But 5.0.0 is, in at least some areas, a big
enough change that mere mindless merging to there from the 4.x line is
out (for example, we've completely rewritten our email / discussion
services) -- yet other things, notably those "serious bugs" (if
they're not in the old discussion services) we do want to merge to
5.0.0. So the book-keeping gets pretty complicated, and the ability
to have Subversion track what hasn't been merged, what has, and what
has been declined, would be a huge help (will be, once we can use it).
You've heard my story of a considerably more complex "poor-sod"
situation, where at a former shop we had as many as 30 "twigs" sprout
from each release (major, minor, or maintenance) for re-engineering
portability to various Unix platforms into code added to the mainline,
plus one "portabilitized" branch that served as a sort of staging area
before delivering those changes back to trunk. (This shop was also,
of course, in crying need of Linux, gcc, and autoconf, but here we
digress.)
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 26 18:03:21 2007