Gee, somehow I knew Jack would give a lengthy reply. :-)
On Nov 26, 2007 11:02 AM, Jack Repenning <jrepenning@collab.net> wrote:
> 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):
I've got 3 of the 4 covered...
>
> - merges during updates
This chapter is about 'merging' in the context of 'branching and
merging', and specifically about how to use the 'svn merge' command.
The book very carefully tries to disambiguate this from the colloquial
use of the word 'merge' during an 'svn update' operation. The chapter
of basic daily workflow talks quite a bit about 'svn update', and how
changes are folded together, and how to resolve conflicts. Thus it's
a deliberate choice not to talk about updates in the 'branching and
merging' chapter.
> - cherry-picking from one branch to another
Got that covered in the 'copying specific changes' part of the
outline. The 'undoing changes' section touches on it as well.
> - whole-branch merge (refresh a feature branch from trunk, and also
> deliver the feature to trunk)
That's the main thrust of the chapter (and always has been): a long
expository example involving a feature branch. In theory, the example
is about to get a whole lot simpler... no more trying to figure out
which ranges to merge!
> - vendor branching (a whole-branch special case, due to open-ended
> persistency)
I hate our vendor branching story, but yes, it's tacked on to the end
of the chapter already, if you look at the outline. That section has
been around for four years, and it's not going to change much. :-/
> 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.)
I agree that the merge-tracking will not only make basic
feature-branches trivial, but also "big mess of branches with lots of
random cherrypicking" much easier to manage as well. The thing is,
I'm not sure how to present the latter scenario in the book chapter
without completely overwhelming the reader. I mean, I suppose I can
talk about the scenario in the abstract, but it won't be more than a
paragraph or two.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 26 20:59:05 2007