[PATCH] Various svnbook fixes

C. Michael Pilato cmpilato at red-bean.com
Wed Aug 17 08:36:52 CDT 2005

If not commented on below, I agree with Max's opinions on the patch.

Max Bowsher wrote:

> Index: appa.xml
> ===================================================================
> --- appa.xml (revision 1614)
> +++ appa.xml (working copy)
> @@ -25,7 +25,7 @@
>     <title>Revision Numbers Are Different Now</title>
>     <para>In CVS, revision numbers are per-file.  This is because CVS
> -      uses RCS as a backend; each file has a corresponding RCS file in
> +      stores its data in RCS files; each file has a corresponding RCS
> file in
>       the repository, and the repository is roughly laid out according
>       to the structure of your project tree.</para>
> New wording as suggested by Ben. OK to apply?


> Index: ch02.xml
> ===================================================================
> --- ch02.xml (revision 1614)
> +++ ch02.xml (working copy)
> @@ -54,7 +54,7 @@
>       example, a client can ask historical questions like, <quote>What
>       did this directory contain last Wednesday?</quote> or <quote>Who
>       was the last person to change this file, and what changes did
> -      they make?</quote> These are the sorts of questions that are at
> +      he make?</quote> These are the sorts of questions that are at
>       the heart of any <firstterm>version control system</firstterm>:
>       systems that are designed to record and track changes to data
>       over time.
> The use of 'they' as a gender-agnostic singular pronoun is pretty
> common, if perhaps not strictly grammatical. I would leave it.

We have tried to us "he" and "she" throughout the book instead of
"they".  +1 on making this change (and others like it).

> Index: ch04.xml
> ===================================================================
> --- ch04.xml (revision 1614)
> +++ ch04.xml (working copy)
> @@ -644,7 +644,7 @@
>               tree-changes.</para>
>           </footnote>
>           The <command>svn merge</command> command, however, can express
> -          tree-changes by directly applying them to your working
> +          changes in tree structure and properties by directly
> applying them to your working
>           copy.</para>
>       </sidebar>
> De-jargonizing! Good!


> @@ -885,7 +885,7 @@
>           Somebody can then run <command>svn log -r9238</command> to
>           read about the exact changeset which fixed the bug, and run
>           <command>svn diff -r9237:9238</command> to see the patch
> -          itself.  And Subversion's merge command also uses revision
> +          itself.  And Subversion's <command>merge</command> command
> also uses revision
>           numbers.  You can merge specific changesets from one branch
>           to another by naming them in the merge arguments:
>           <command>svn merge -r9237:9238</command> would merge
> Here we need to determine a convention. Does a subcommand name without
> a leading "svn" go in <command/> tags? Think especially of the case of
> "diff" which is a unix command in its own right. Elsewhere in the
> book, these have been put into <literal/> tags... which might actually
> end up formatted the same, now I think about it. Further instances of
> this kind of change are snipped from this email.

Yep, these are <literal>s.

> @@ -1010,18 +1010,18 @@
> ...
>           notice that they're unrelated and first attempt to delete
>           the old file, then add the new file;  you would see a
> -          <literal>D  foo.c</literal> followed by a <literal>A
> -          foo.c</literal>.</para>
> +          <literal>D  foo.c</literal> followed by a
> +          <literal>A  foo.c</literal>.</para>
> Good. Do we need to check for more cases like this?

That is a good catch, but I disagree with the fix.  I think that chunk
should be reworked to keep screen output out of the main paragraph:

    ...notice that they're unrelated and first attempt to delete the old
    file, then add the new file; the output indicate a deletion followed
    by an add:

        D  foo.c
        A  foo.c

> Index: ch05.xml
> ===================================================================
> --- ch05.xml (revision 1614)
> +++ ch05.xml (working copy)
> @@ -1120,7 +1120,7 @@
>           other queries, displaying subsets of bits of information
>           we've mentioned previously, reporting which paths were
>           modified in a given revision or transaction, showing textual
> -          and property differences made to files and directories, and
> +          and property differences made to files, symlinks and
> directories, and
>           so on.  The following is a brief description of the current
>           list of subcommands accepted by <command>svnlook</command>,
>           and the output of those subcommands:</para>
> Symlinks can sort of be considered a kind of file... and leaving it
> out here avoids confusing people who don't know about symlinks.

Yeah, let's keep it simple.

> Index: ch06.xml
> ===================================================================
> --- ch06.xml (revision 1614)
> +++ ch06.xml (working copy)
> @@ -5,7 +5,7 @@
>     <para>A Subversion repository can be accessed simultaneously by
>       clients running on the same machine on which the repository
> -      resides using the <literal>file:///</literal> method.  But the
> +      resides using the <literal>file://</literal> method.  But the
>       typical Subversion setup involves a single server machine being
>       accessed from clients on computers all over the office—or,
>       perhaps, all over the world.</para>
> I think this should stay as is. People who don't care about the
> details will be more likely to get it right, and people who do care
> will understand that the third slash is in recognition of the fact
> that the file:// URL scheme authority component should be left empty.

Disagree.  +1 on the change.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.red-bean.com/pipermail/svnbook-dev/attachments/20050817/c6cb8428/attachment-0001.html>

More information about the svnbook-dev mailing list