[svnbook commit] r3230 - trunk/src/en/book

sussman noreply at red-bean.com
Sat Aug 2 11:50:33 CDT 2008


Author: sussman
Date: Sat Aug  2 11:50:33 2008
New Revision: 3230

Log:
Enter 2nd-round copyedits (most of them) for Chapter 1.

Modified:
   trunk/src/en/book/ch01-fundamental-concepts.xml

Modified: trunk/src/en/book/ch01-fundamental-concepts.xml
==============================================================================
--- trunk/src/en/book/ch01-fundamental-concepts.xml	(original)
+++ trunk/src/en/book/ch01-fundamental-concepts.xml	Sat Aug  2 11:50:33 2008
@@ -51,7 +51,7 @@
       <emphasis>previous</emphasis> states of the filesystem.  For
       example, a client can ask historical questions such
       as <quote>What did this directory contain last
-      Wednesday?</quote> or <quote>Who was the last person to change
+      Wednesday?</quote> and <quote>Who was the last person to change
       this file, and what changes did he make?</quote> These are the
       sorts of questions that are at the heart of
       any <firstterm>version control system</firstterm>: systems that
@@ -68,7 +68,7 @@
     <para>The core mission of a version control system is to enable
       collaborative editing and sharing of data.  But different
       systems use different strategies to achieve this.  It's
-      important to understand these different strategies for a couple
+      important to understand these different strategies, for a couple
       of reasons.  First, it will help you compare and contrast
       existing version control systems, in case you encounter other
       systems similar to Subversion.  Beyond that, it will also help
@@ -90,7 +90,7 @@
         linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>.
         Suppose we have two coworkers, Harry and Sally.  They each
         decide to edit the same repository file at the same time.  If
-        Harry saves his changes to the repository first, then it's
+        Harry saves his changes to the repository first, it's
         possible that (a few moments later) Sally could accidentally
         overwrite them with her own new version of the file.  While
         Harry's version of the file won't be lost forever (because the
@@ -119,7 +119,7 @@
         model, the repository allows only one person to change a file
         at a time.  This exclusivity policy is managed using locks.
         Harry must <quote>lock</quote> a file before he can begin
-        making changes to it.  If Harry has locked a file, then Sally
+        making changes to it.  If Harry has locked a file, Sally
         cannot also lock it, and therefore cannot make any changes to
         that file.  All she can do is read the file and wait for
         Harry to finish his changes and release his lock.  After Harry
@@ -205,7 +205,7 @@
         same file A within their copies.  Sally saves her changes to
         the repository first.  When Harry attempts to save his changes
         later, the repository informs him that his file A is
-        <firstterm>out-of-date</firstterm>.  In other words, that file
+        <firstterm>out of date</firstterm>.  In other words, file
         A in the repository has somehow changed since he last copied
         it.  So Harry asks his client to <firstterm>merge</firstterm>
         any new changes from the repository into his working copy of
@@ -261,8 +261,8 @@
         <title>When Locking Is Necessary</title>
 
         <para>While the lock-modify-unlock model is considered
-          generally harmful to collaboration, there are still times
-          when locking is appropriate.</para>
+          generally harmful to collaboration, sometimes
+          locking is appropriate.</para>
 
         <para>The copy-modify-merge model is based on the assumption
           that files are contextually mergeable—that is, that the
@@ -277,9 +277,8 @@
 
         <para>While Subversion is primarily a copy-modify-merge
           system, it still recognizes the need to lock an occasional
-          file, and thus provides mechanisms for this.  This feature is
-          discussed later in this book in
-          <xref linkend="svn.advanced.locking"/>.</para>
+          file, and thus provides mechanisms for this.  We discuss
+          this feature in <xref linkend="svn.advanced.locking"/>.</para>
 
       </sidebar>
 
@@ -350,8 +349,8 @@
         (non-URL) form of a path on Windows uses backslashes.</para>
 
       <note>
-        <para>Subversion's <literal>file://</literal> URLs cannot be
-          used in a regular web browser the way typical
+        <para>You cannot use Subversion's <literal>file://</literal> URLs
+          in a regular web browser the way typical
           <literal>file://</literal> URLs can.  When you attempt to view
           a <literal>file://</literal> URL in a regular web browser, it
           reads and displays the contents of the file at that location
@@ -372,20 +371,20 @@
 </screen>
 
       <para>then Subversion will escape the unsafe characters
-        and behave as if you had typed:</para>
+        and behave as though you had typed:</para>
 
       <screen>
 $ svn checkout http://host/path%20with%20space/project/espa%C3%B1a
 </screen>
 
-      <para>If the URL contains spaces, be sure to place it within quote
-        marks, so that your shell treats the whole thing as a single
+      <para>If the URL contains spaces, be sure to place it within quotation
+        marks so that your shell treats the whole thing as a single
         argument to the <command>svn</command> program.</para>
 
       <sidebar id="svn.basic.in-action.wc.sb-1">
         <title>Repository URLs</title>
 
-        <para>Subversion repositories can be accessed through many
+        <para>You can access Subversion repositories through many
           different methods—on local disk or through various
           network protocols, depending on how your administrator has
           set things up for you.  A repository location, however, is
@@ -533,7 +532,7 @@
         in</firstterm>) changes to the repository.</para>
 
       <para>To publish your changes to others, you can use
-        Subversion's <command>svn commit</command> command.</para>
+        Subversion's <command>svn commit</command> command:</para>
 
       <screen>
 $ svn commit button.c -m "Fixed a typo in button.c."
@@ -545,7 +544,7 @@
       <para>Now your changes to <filename>button.c</filename> have
         been committed to the repository, with a note describing your
         change (namely, that you fixed a typo).  If another user
-        checks out a working copy of <filename>/calc</filename>, they
+        checks out a working copy of <filename>/calc</filename>, she
         will see your changes in the latest version of the
         file.</para>
 
@@ -593,11 +592,11 @@
         changes to any number of files and directories as a single
         atomic transaction.  In your working copy, you can change
         files' contents; create, delete, rename, and copy files and
-        directories; then commit a complete set of changes as an
+        directories; and then commit a complete set of changes as an
         atomic transaction.</para>
 
       <para>By atomic transaction, we mean simply this: either all of
-        the changes happen in the repository, or none of them happen.
+        the changes happen in the repository, or none of them happens.
         Subversion tries to retain this atomicity in the face of
         program crashes, system crashes, network problems, and other
         users' actions.</para>
@@ -633,7 +632,7 @@
           revision N represents the state of the repository filesystem
           after the Nth commit.  When Subversion users talk
           about <quote>revision 5 of
-          <filename>foo.c</filename></quote>, they really mean
+          <filename>foo.c</filename>,</quote> they really mean
           <quote><filename>foo.c</filename> as it appears in revision
           5.</quote> Notice that in general, revisions N and M of a
           file do <emphasis>not</emphasis> necessarily differ!  Many
@@ -671,7 +670,7 @@
       <para>Suppose that, at this point, Sally commits a change to
         <filename>integer.c</filename>, creating revision 6.  If you
         use <command>svn update</command> to bring your working copy
-        up to date, then it will look like this:</para>
+        up to date, it will look like this:</para>
 
       <screen>
 calc/Makefile:6
@@ -705,7 +704,7 @@
         <listitem>
           <para>What revision your working file is based on (this is
             called the file's <firstterm>working
-            revision</firstterm>) and</para>
+            revision</firstterm>)</para>
         </listitem>
 
         <listitem>
@@ -739,7 +738,7 @@
             <para>The file has been changed in the working directory,
               and no changes to that file have been committed to the
               repository since you last updated.  There are local
-              changes that have not been committed to the repository,
+              changes that have not been committed to the repository;
               thus an <command>svn commit</command> of the file will
               succeed in publishing your changes, and an <command>svn
               update</command> of the file will do nothing.</para>
@@ -747,7 +746,7 @@
         </varlistentry>
 
         <varlistentry>
-          <term>Unchanged, and out-of-date</term>
+          <term>Unchanged, and out of date</term>
 
           <listitem>
             <para>The file has not been changed in the working
@@ -762,7 +761,7 @@
         </varlistentry>
 
         <varlistentry>
-          <term>Locally changed, and out-of-date</term>
+          <term>Locally changed, and out of date</term>
 
           <listitem>
             <para>The file has been changed both in the working
@@ -797,7 +796,7 @@
         mix of different working revision numbers.  Unfortunately,
         this flexibility tends to confuse a number of new users.  If
         the earlier example showing mixed revisions perplexed you,
-        here's a primer on both why the feature exists and how to make
+        here's a primer on why the feature exists and how to make
         use of it.</para>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
@@ -806,11 +805,11 @@
 
         <para>One of the fundamental rules of Subversion is that
           a <quote>push</quote> action does not cause
-          a <quote>pull,</quote> nor the other way around.  Just
+          a <quote>pull,</quote> nor vice versa.  Just
           because you're ready to submit new changes to the repository
           doesn't mean you're ready to receive changes from other
           people.  And if you have new changes still in progress,
-          then <command>svn update</command> should gracefully merge
+          <command>svn update</command> should gracefully merge
           repository changes into your own, rather than forcing you to
           publish them.</para>
 
@@ -833,7 +832,7 @@
           update</command>, and <command>svn commit</command> doesn't
           pull down new changes.  If, on the other hand,
           <command>svn commit</command> were to automatically download
-          the newest changes, then it would be possible to set the
+          the newest changes, it would be possible to set the
           entire working copy to revision 15—but then we'd be
           breaking the fundamental rule of <quote>push</quote>
           and <quote>pull</quote> remaining separate actions.
@@ -852,7 +851,7 @@
         <title>Mixed revisions are normal</title>
 
         <para>The fact is, <emphasis>every time</emphasis> you run
-          <command>svn commit</command>, your working copy ends up
+          <command>svn commit</command> your working copy ends up
           with some mixture of revisions.  The things you just
           committed are marked as having larger working revisions than
           everything else.  After several commits (with no updates
@@ -862,7 +861,7 @@
           your mixture of working revisions, use the <command>svn
           status</command> command with the <option>--verbose</option> option (see <xref 
           linkend="svn.tour.cycle.examine.status"/> for more
-          information.)</para>
+          information).</para>
 
         <para>Often, new users are completely unaware that their
           working copy contains mixed revisions.  This can be
@@ -871,11 +870,11 @@
           example, the <command>svn log</command> command is used to
           display the history of changes to a file or directory (see
           <xref linkend="svn.tour.history.log"/>).  When the user
-          invokes this command on a working copy object, they expect
+          invokes this command on a working copy object, he expects
           to see the entire history of the object.  But if the
           object's working revision is quite old (often because
           <command>svn update</command> hasn't been run in a long
-          time), then the history of the <emphasis>older</emphasis>
+          time), the history of the <emphasis>older</emphasis>
           version of the object is shown.</para>
 
       </sect3>
@@ -886,7 +885,7 @@
 
         <para>If your project is sufficiently complex, you'll discover
           that it's sometimes nice to
-          forcibly <firstterm>backdate</firstterm> (or, update to a
+          forcibly <firstterm>backdate</firstterm> (or update to a
           revision older than the one you already have) portions of
           your working copy to an earlier revision; you'll learn how
           to do that in <xref linkend="svn.tour"/>.  Perhaps you'd
@@ -910,7 +909,7 @@
         <para>First, you cannot commit the deletion of a file or
           directory that isn't fully up to date.  If a newer version
           of the item exists in the repository, your attempt to delete
-          will be rejected in order to prevent you from accidentally
+          will be rejected to prevent you from accidentally
           destroying changes you've not yet seen.</para>
 
         <para>Second, you cannot commit a metadata change to a
@@ -933,25 +932,25 @@
   <sect1 id="svn.basic.summary">
     <title>Summary</title>
     
-    <para>We've covered a number of fundamental Subversion concepts in
+    <para>We covered a number of fundamental Subversion concepts in
       this chapter:</para>
 
     <itemizedlist>
       <listitem>
-        <para>We've introduced the notions of the central repository,
+        <para>We introduced the notions of the central repository,
           the client working copy, and the array of repository
           revision trees.</para>
       </listitem>
 
       <listitem>
-        <para>We've seen some simple examples of how two collaborators
+        <para>We saw some simple examples of how two collaborators
           can use Subversion to publish and receive changes from one
           another, using the <quote>copy-modify-merge</quote>
           model.</para>
       </listitem>
 
       <listitem>
-        <para>We've talked a bit about the way Subversion tracks and
+        <para>We talked a bit about the way Subversion tracks and
           manages information in a working copy.</para>
       </listitem>
 




More information about the svnbook-dev mailing list