Review of fitz's chapter 2
Brian W. Fitzpatrick
fitz at red-bean.com
Sun Feb 25 14:57:56 CST 2007
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
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.
More information about the svnbook-dev