Review of Chapter 4: Branching and Merging

C. Michael Pilato cmpilato at
Sat Feb 24 15:57:18 CST 2007

Ben Collins-Sussman wrote:
> Question:  in the 'undoing changes' section, which shows a reverse
> merge like -r88:87, should I use the slightly obtuse 'reverse change'
> notation of '-c -88' ?  I fear that may cause confusion, and might be
> better left for the command reference section.

You could always show both.  It's a great, practical way of
demonstrating the "negated revision" use of --change (-c).

>> "they're the classic sign of driver error."  I suspect the tendency of
>> Windows users is to interpret "driver error" as something entirely
>> different than what you mean.  Let's avoid this jargon.
> Sure, I changed it to 'user' error instead.  (But c'mon, you seriously
> think a windows user is going to think we suddenly started talking
> about hardware drivers in the middle of this chapter?  :-)  People
> have better context-processors than you give them credit for.)

No, I don't *really* think that.  But "driver error", I think, is maybe
just barely on the far side of the Obscure Jargon Phrases lines.

>> "A lesser-known fact about Subversion is that it lacks "true renames" —
>> the svn move command is nothing more than an aggregation of svn copy and
>> svn delete."  While it is true that we don't have "true renames",
>> dropping that piece of terminology like that without a suitable
>> explanation of what you mean is somewhat pointless.  (And besides, I
>> don't think it's a lesser-known fact to folks that use the operation.
>> Further, if it *is* a lesser-known fact, it's because the Subversion
>> developer community obscures it when we brag that we have support for
>> moves when, in fact, we have merely a close approximation of such
>> support.)
> OK, I've removed the phrase 'true renames', so as to not make users
> wonder what that phrase means (and begin speculating wildly).  I *do*
> still have to say that 'mv == cp + rm', however.

Oh, absolutely!  (Sorry, I had meant to explicit +1 that portion of your

>> "The Subversion project has plans, however, to someday implement a
>> command that would accomplish the task of permanently deleting
>> information."  Objection, Your Honor -- heresay.
> It's not heresay, it's been discussed to death a thousand times.  It's
> in the issue tracker.  People have worked on the problem many times
> and backed away in frustration (including you!).  It's such a hot
> issue, we have users endlessly writing nagging comments in the issue
> tracker to finish it... they're even volunteering to help.  I've never
> seen a single svn developer object to the idea, in fact... *everyone*
> wants it, and hasn't been able to make it happen yet.  It's so highly
> regarded, in fact, that it's on everyone's 'to do' list for svn 2.0
> (assuming we can't make it happen in 1.x).
> That's not 'heresay', that's the "community actively struggling for
> years on the problem."  It's exactly what the text says:  that the
> community 'has plans' to make it happen.

Eh.  What the Subversion community has done thus far is talk about how
hard the problem is, and from there any semblance of a roadmap toward
the solving the problem is accompanied by frantically waving hands.  But
you're right, obliterate is a pretty seriously considered feature
request.  I'll concede on this one.

> Ah yes, thanks, I remember this TODO.   I've changed the title to
> "Traversing Branches".  if you have better suggestions, I'm all ears.

I can't think of a *short* title.  :-)  "Pointing Your Working Copy at a
Different Repository URL" feels ... wordy.

> Sometimes the 'long story' format works best, particularly when the
> concepts themselves build on each other.   All of our chapters sort of
> skim the line between 'story' and 'reference', and this one tends to
> be more on the story-end of the scale.  If someone has no experience
> with branches and tags, they can't just figure them out by opening
> chapter 4 to a random section and skimming... I can't imagine this
> chapter ever as a reference.  This is one of those topics that really
> requires focused long-form reading and absorbtion of concepts.

Yeah, I agree.  I think it's an exception to the rule in this way -- the
concepts pretty much demand it.

C. Michael Pilato <cmpilato at>

"The Christian ideal has not been tried and found wanting.  It has
 been found difficult; and left untried."  -- G. K. Chesterton

More information about the svnbook-dev mailing list