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