Review of fitz's chapter 2

[Brian W. Fitzpatrick]

On 2/25/07, C. Michael Pilato <cmpilato at red-bean.com> wrote:
> Ben Collins-Sussman wrote:
> > * "Comparing repository to repository" section;
> >
> >   Instead of the stilted "svn diff --revision 2:3" example, how about
> >   the hot new "svn diff -c 3"?  (There's also a --revision 4:5 example
> >   that can be replaced.)  This is a great opportunity to introduce the
> >   -c switch and explain how it relates to the -r switch.  I'm using -c
> >   a lot now in the branching/merging chapter, so this would set us up
> >   really nicely.
>
> This section could really stand to have an example of 'svn diff --old
> OLD_BASE --new NEW_BASE RELATIVE_TARGET [...], too.  (As could Chapter
> 4, for that matter.)  I'm really shocked that the only place this syntax
> is mentioned is in the command reference -- I use it *all the time* to
> compare two branches or tags ("What changed between Subversion 1.4.0 and
> 1.4.3?")

I think this would work better in Chapter 4, actually.  Diffing
between branches isn't really "Basic", IMO.

> > * "Fetching older repository snapshots" section:
> >
> >   A lot of newbies learn about 'svn up -r X', and assume that's the
> >   proper way to 'undo' changes.  We need an explanation in here that
> >   one *cannot* commit changes that come from backdated working
> >   copies.  Put a xref pointer to the 'undoing changes' section in
> >   chapter 4.
>
> Well, yeah, but when you explain it, don't give misinformation.  :-)
>
> You *can* commit changes from a backdated working copy, because a
> backdated working copy looks exactly like and out-of-date one, and the
> ability to commit from a not-fully-updated working copy is a core
> principle of Subversion's design.  But can you can't commit changes from
> such a working copy to files *that have been modified in younger revisions*.

Yep.  Got it right.

Thanks,

-Fitz