The minor corrections are obvious, but could someone say whether they
agree with my three "clarifications"? (The explanation of "ci" does not
necessarily have to go where I put it, but I think it should go in the
book somewhere.)
Clarifications and minor corrections.
* doc/book/book/ch02.xml:
Use "mdash" entity instead of literal dashes.
* doc/book/book/ch03.xml:
Change wording to encourage users to issue "svn resolve" rather than
removing the temporary files manually.
Change of emphasis for clarity.
Insert a missing word.
* doc/book/book/ch04.xml:
Use "mdash" entity instead of literal dashes.
Fix grammar/typo.
* doc/book/book/ch05.xml:
Fix grammar/typos.
* doc/book/book/ch06.xml:
Fix grammar/typos.
* doc/book/book/ch07.xml:
Fix spelling.
* doc/book/book/ch08.xml:
Explain why "ci" and not "co" is the abbreviation for "commit".
Fix spelling.
- Julian
Index: doc/book/book/ch02.xml
===================================================================
--- doc/book/book/ch02.xml (revision 5485)
+++ doc/book/book/ch02.xml (working copy)
@@ -17,7 +17,7 @@
<para>Even though the examples in this chapter show people sharing
collections of program source code, keep in mind that Subversion
- can manage any sort of file collection -- it's not limited to
+ can manage any sort of file collection—it's not limited to
helping computer programmers.</para>
</simplesect>
Index: doc/book/book/ch03.xml
===================================================================
--- doc/book/book/ch03.xml (revision 5485)
+++ doc/book/book/ch03.xml (working copy)
@@ -1293,9 +1293,10 @@
</itemizedlist>
<para>Once you've resolved the conflict, you need to let
- Subversion know by removing the three temporary files. When
- those files are gone, Subversion no longer considers the file
- to be in a state of conflict anymore.</para>
+ Subversion know by running <command>svn resolve</command>.
+ This removes the three temporary files
+ and Subversion no longer considers the file
+ to be in a state of conflict.</para>
<screen>
$ svn resolve sandwich.txt
@@ -1446,8 +1447,8 @@
argument. In any case, you want to be careful and only run
<command>svn resolve</command> when you're certain that you've
fixed the conflict in your file—once the temporary files
- are removed, Subversion will let you commit a file with
- conflict markers.</para>
+ are removed, Subversion will let you commit the file even if
+ it still contains conflict markers.</para>
</sect2>
@@ -1465,7 +1466,7 @@
to the new revision you create. If your log message is
brief, you may wish to supply it on the command line using
the <option>--message</option> (or
- <option>-m</option>):</para>
+ <option>-m</option>) option:</para>
<screen>
$ svn commit --message "Corrected number of cheese slices."
Index: doc/book/book/ch04.xml
===================================================================
--- doc/book/book/ch04.xml (revision 5485)
+++ doc/book/book/ch04.xml (working copy)
@@ -117,7 +117,7 @@
when you're finished, you might find it very difficult to commit
your changes. Sally (or others) may have made many other
changes in the repository that are difficult to merge into your
- working copy -- especially all at once.</para>
+ working copy—especially all at once.</para>
<para>The better solution is to create your own branch, or line of
development, in the repository. This allows you to save your
@@ -129,13 +129,13 @@
<sect2 id="svn-ch-4-sect-2.1">
<title>Creating a branch</title>
- <para>Creating a branch is very simple -- you make a copy of the
+ <para>Creating a branch is very simple—you make a copy of the
project in the repository using the <command>svn
copy</command> command. Subversion is not only able to copy
single files, but whole directories as well. In this case,
you want to make a copy of the
<filename>/trunk/calc</filename> directory. Where should the
- new copy live? Whereever you wish -- it's a matter of project
+ new copy live? Whereever you wish—it's a matter of project
policy. Let's say that your team has a policy of creating
branches in the <filename>/branches/calc</filename> area of
the repository, and you want to name your branch
@@ -229,19 +229,19 @@
<para>Subversion's repository has a clever design. When you
copy a directory, you don't need to worry about the
- repository growing huge -- Subversion doesn't actually
+ repository growing huge—Subversion doesn't actually
duplicate any data. Instead, it creates a new directory
entry that points to an <emphasis>existing</emphasis> tree.
If you're a Unix user, this is the same concept as a
hard-link. From there, the copy is said to be "lazy". That
is, if you commit a change to one file within the copied
- directory, then only that file changes -- the rest of the
+ directory, then only that file changes—the rest of the
files continue to exist as links to the original files in
the original directory.</para>
<para>This is why you'll often hear Subversion users talk
about "cheap copies". It doesn't matter how large the
- directory is -- it takes a very tiny, constant amount of
+ directory is—it takes a very tiny, constant amount of
time to make a copy of it. In fact, this feature is the
basis of how commits work in Subversion: each revision is a
"cheap copy" of the previous revision, with a few items
@@ -382,7 +382,7 @@
<orderedlist>
<listitem>
<para>Unlike many other version control systems,
- Subversion's branches exist a <emphasis>normal filesystem
+ Subversion's branches exist as <emphasis>normal filesystem
directories</emphasis> in the repository, not in some
extra dimension.</para>
</listitem>
Index: doc/book/book/ch05.xml
===================================================================
--- doc/book/book/ch05.xml (revision 5485)
+++ doc/book/book/ch05.xml (working copy)
@@ -51,7 +51,7 @@
<para>Conceptually speaking, a Subversion repository is a
sequence of directory trees. Each tree is a snapshot of how
the files and directories versioned in your repository looked
- at various points in time. These snapshots are created as a
+ at one point in time. These snapshots are created as a
result of client operations, and are called revisions.</para>
<para>Every revision begins life as a transaction tree. When
@@ -69,7 +69,7 @@
<para>At the moment, updates work in a similar way. The client
builds a temporary transaction tree that mirrors the state of
the working copy. The repository then compares that
- transaction tree with the revision tree at the request
+ transaction tree with the revision tree at the requested
revision (usually the most recent, or <quote>youngest</quote>
tree), and sends back information that informs the client
about what changes are needed to transform their working copy
Index: doc/book/book/ch06.xml
===================================================================
--- doc/book/book/ch06.xml (revision 5485)
+++ doc/book/book/ch06.xml (working copy)
@@ -429,7 +429,7 @@
<term><literal>diff3-cmd</literal></term>
<listitem>
<para>This specifies the absolute path of a three-way
- differencing program. Subversion uses this program
+ differencing program. Subversion uses this program to
merge changes made by the user with those received
from the repository. The default value is the path of
the GNU diff3 utility, as determined by the Subversion
@@ -1344,7 +1344,7 @@
will continue to display the same substituted keyword value
as before—until you update your working copy. At that
time the keywords in your <filename>weather.txt</filename>
- file will be re-substituted again with information that
+ file will be re-substituted with information that
reflects the most recent known commit to that file.</para>
</sect3>
Index: doc/book/book/ch07.xml
===================================================================
--- doc/book/book/ch07.xml (revision 5485)
+++ doc/book/book/ch07.xml (working copy)
@@ -1614,11 +1614,11 @@
properly format your source code for consistency with the rest
of the codebase, how to describe your proposed changes with an
effective change log message, how to test your changes, and so
- on. Commit priveleges on the Subversion source repository are
+ on. Commit privileges on the Subversion source repository are
earned—a government by meritocracy.
<footnote>
<para>While this may superficially appear as some sort of
- elitism, this "earn your commit priveleges" notion is
+ elitism, this "earn your commit privileges" notion is
about efficiency—whether it costs more in time and
effort to review and apply someone else's changes that are
likely to be safe and useful, versus the potential costs
@@ -1687,7 +1687,7 @@
developers list containing your log message and the output of
<command>svn diff</command> (from the top of your Subversion
working copy). If the community members consider your changes
- acceptable, someone who has commit priveleges (permission to
+ acceptable, someone who has commit privileges (permission to
make new revisions in the Subversion source repository) will
add your changes to the public source code tree. Recall that
permission to directly commit changes to the repository is
Index: doc/book/book/ch08.xml
===================================================================
--- doc/book/book/ch08.xml (revision 5485)
+++ doc/book/book/ch08.xml (working copy)
@@ -670,7 +670,7 @@
<refsect1>
<title>Alternate names</title>
- <para>ci</para>
+ <para>ci (short for Check In; not "co" which is short for Check Out)</para>
</refsect1>
<refsect1>
@@ -1065,7 +1065,7 @@
<para>If the alternate syntax is used, the server compares
URL1 and URL2 at revisions N and M respectively. If
- either N or M are ommitted, a value of HEAD is
+ either N or M are omitted, a value of HEAD is
assumed.</para>
</refsect1>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 27 19:14:13 2003