[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