[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] Subversion's Book Proofreading

From: Francois Beausoleil <fbeausoleil_at_ftml.net>
Date: 2003-02-27 15:29:32 CET

Hi !

I have read chapters 0 through 6. I made an svn diff of the changes I
made so far. A few spelling mistakes mostly.

I also identified a few areas where the formatting is wrong. This
mostly happens in lists. The term in the first column overwrites the
second one. I identified the formatting mistakes with ###TODO-FORMAT
comments. This will most probably involve changing the stylesheet. I
will leave that for last.

Thanks for the great work !
Francois Beausoleil (fbos@users.sourceforge.net)
Developper of Java Gui Builder - http://jgb.sourceforge.net/

----------------------------- BEGIN PATCH -----------------------------
Index: ch00.xml
===================================================================
--- ch00.xml (revision 5128)
+++ ch00.xml (working copy)
@@ -30,7 +30,7 @@
        feel") as CVS, and by attempting to fix most of CVS's noticeable
        flaws. While the result isn't necessarily the next great
        evolution in version control design, Subversion
- <emphasis>is</emphasis> is very powerful, very useable, and very
+ <emphasis>is</emphasis> very powerful, very useable, and very
        flexible.
      </para>

Index: ch01.xml
===================================================================
--- ch01.xml (revision 5128)
+++ ch01.xml (working copy)
@@ -171,6 +171,9 @@
        </varlistentry>

        <varlistentry>
+ <!-- ###TODO-FORMAT: This is too long - The final 'ing' of
+ tagging enters the next column
+ -->
          <term>Efficient branching and tagging</term>
          <listitem>
            <para>
@@ -252,6 +255,10 @@

      <variablelist>

+ <!-- ###TODO-FORMAT: This list is nice, but the left column
+ needs work. It crosses over onto the
+ second one.
+ -->
        <varlistentry>
          <term>svn</term>
          <listitem>
Index: ch02.xml
===================================================================
--- ch02.xml (revision 5128)
+++ ch02.xml (working copy)
@@ -609,6 +609,9 @@
          </varlistentry>

          <varlistentry>
+ <!-- ###TODO-FORMAT: Entry too long, again. It crosses over to
+ the next column
+ -->
            <term>Unchanged, and out-of-date</term>

            <listitem><para>The file has not been changed in the working
Index: ch03.xml
===================================================================
--- ch03.xml (revision 5128)
+++ ch03.xml (working copy)
@@ -125,6 +125,8 @@
          </varlistentry>

          <varlistentry>
+ <!-- ###TODO: Too large for the column-width.
+ -->
            <term>COMMITTED</term>
            <listitem>
              <para>The last revision in which an item changed.</para>
@@ -967,7 +969,7 @@
          <para>Notice the two asterisks: if you were to run
            <command>svn update</command> at this point, you would
            receive changes to <filename>README</filename>
- and<filename>trout.c</filename>. This tells you some very
+ and <filename>trout.c</filename>. This tells you some very
            useful information&mdash;you'll need to update and get the
            server changes on <filename>README</filename> before you
            commit, or the repository will reject your commit for being
@@ -1469,7 +1471,7 @@

        <screen>
  $ svn commit --message "Corrected number of cheese slices."
-Sending sandwich
+Sending sandwich.txt
  Transmitting file data .
  Committed revision 3.
        </screen>
Index: ch05.xml
===================================================================
--- ch05.xml (revision 5128)
+++ ch05.xml (working copy)
@@ -238,6 +238,8 @@
          </listitem>
        </varlistentry>
       <varlistentry>
+ <!-- ###TODO-FORMAT: README crosses over into the next column
+ -->
          <term>README</term>
          <listitem>
            <para>A file which merely informs its readers that they
@@ -697,6 +699,8 @@
            </varlistentry>

            <varlistentry>
+ <!-- ###TODO-FORMAT: dirs-changed shows up in the next column
+ -->
              <term><literal>dirs-changed</literal></term>
              <listitem>
                <para>List the directories in the tree that were
Index: ch06.xml
===================================================================
--- ch06.xml (revision 5128)
+++ ch06.xml (working copy)
@@ -441,6 +441,9 @@
              </listitem>
            </varlistentry>
            <varlistentry>
+ <!-- ###TODO-FORMAT: Overwrites part of the right-hand
+ side column
+ -->
              <term><literal>diff3-has-program-arg</literal></term>
              <listitem>
                <para>This flag should be set to <literal>true</literal>
@@ -1381,7 +1384,7 @@
            line.</para>

          <para>This sensitivity to foreign EOL markers can become
- frustraing for folks who share a file across different
+ frustrating for folks who share a file across different
            operating systems. For example, consider a source code
            file, and developers that edit this file on both Windows and
            Unix systems. If all the developers always use tools which
@@ -1404,7 +1407,7 @@
            Or, he can simply commit the file&mdash;new EOL markers and
            all.</para>

- <para>The result of scenarios like there include wasted time
+ <para>The result of scenarios like these include wasted time
            and unnecessary modifications to committed files. Wasted
            time is painful enough. But when commits change every line
            in a file, this complicates the job of determining which of
@@ -1527,6 +1530,7 @@
        gets the benefit of the externals definition. In other words,
        once one person has made the effort to define those nested
        working copy checkouts, no one else has to
+ <!-- ###TODO-FORMAT: Correct formatting mistake ? -->
        bother&mdash;Subversion will, upon checkout of the original
        working copy, also checkout the external working copies.</para>

@@ -1627,7 +1631,7 @@
        house its custom modifications to the third-party data in some
        disjointed fashion, such as using patch files or full-fledged
        alternate versions of files and directories. But these quickly
- become maintainance headaches, requiring some mechanism by which
+ become maintenance headaches, requiring some mechanism by which
        to apply your custom changes to the third-party data, and
        necessitating regeneration of those changes with each successive
        version of the third-party data that you track.</para>

------------------------------ END PATCH ------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 27 15:30:11 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.