[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?
+1
> 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!
+1
> @@ -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