Review of fitz's chapter 2

C. Michael Pilato cmpilato at red-bean.com
Sun Feb 25 12:57:54 CST 2007


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?")

> * "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*.

-- 
C. Michael Pilato <cmpilato at red-bean.com>

"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