Index: ch00.xml
===================================================================
--- ch00.xml (revision 11207)
+++ ch00.xml (working copy)
@@ -586,13 +586,13 @@
Client auto-escaping of URIs and IRIs
- In the 1.0 commandline client, users had to escape
+ In the 1.0 command-line client, users had to escape
URLs manually. The client only accepted legally
correct URLs, such as
http://host/path%20with%20space/project/espa%F1a.
- The 1.1 commandline client now knows how to do what
+ The 1.1 command-line client now knows how to do what
web-browsers have been doing for long time: it
- auto-escapes characters like spaces and other upper-ascii
+ auto-escapes characters like spaces and other upper-ASCII
international characters, as long as the user places the
URL in quotes to protect characters from the shell:
"http://host/path with
Index: ch01.xml
===================================================================
--- ch01.xml (revision 11207)
+++ ch01.xml (working copy)
@@ -174,7 +174,7 @@
Additionally, in CVS you cannot replace a versioned file
with some new thing of the same name without the new item
inheriting the history of the old—perhaps completely
- unrelated— file. With Subversion, you can add,
+ unrelated—file. With Subversion, you can add,
delete, copy, and rename both files and directories. And
every newly added file begins with a fresh, clean
history all its own.
@@ -197,7 +197,7 @@
Versioned metadataEach file and directory has a set of
- properties—keys and their values— associated
+ properties—keys and their values—associated
with it. You can create and store any arbitrary key/value
pairs you wish. Properties are versioned over time, just
like file contents.
@@ -433,7 +433,7 @@
The following example assumes that you have
- svn, the Subversion commandline client, and
+ svn, the Subversion command-line client, and
svnadmin, the administrative tool, ready to
go. It also assumes that your svn client has
been compiled against Berkeley DB. To verify this, run
Index: ch02.xml
===================================================================
--- ch02.xml (revision 11207)
+++ ch02.xml (working copy)
@@ -157,7 +157,7 @@
powerless to prevent the problem—yet it somehow
provided a false sense of security. It's easy for Harry and
Sally to imagine that by locking files, each is beginning a
- safe, insulated task, and thus inhibits them from
+ safe, insulated task, and thus not bother
discussing their incompatible changes early
on.
@@ -306,7 +306,7 @@
with locking or reserving resources, but it doesn't; it simply
creates a private copy of the project for you.) For example,
if you check out /calc, you will get a
- working copy like this:
+ working copy like this:
$ svn checkout http://svn.example.com/repos/calc
@@ -378,7 +378,7 @@
syntax, allowing for server names and port numbers to be
specified as part of the URL. Remember that the
file: access method is valid only for
- locations on the same server as the client—in fact, in
+ locations on the client—in fact, in
accordance with convention, the server name portion of the
URL is required to be either absent or
localhost:
@@ -503,7 +503,7 @@
numbers, starting at 0, stretching from left to right. Each
revision number has a filesystem tree hanging below it, and
each tree is a snapshot of the way the
- repository looked after each commit.
+ repository looked after a commit.
- Sally's changes to integer.c will
+ Sally's change to integer.c will
appear in your working copy, and your change will still be
present in button.c. In this example,
the text of Makefile is identical in
@@ -608,7 +608,7 @@
to the repository since its working revision. A
svn commit of the file will do nothing,
and an svn update of the file will do
- nothing.
+ nothing.
Index: ch03.xml
===================================================================
--- ch03.xml (revision 11207)
+++ ch03.xml (working copy)
@@ -201,7 +201,7 @@
Revision DatesAnywhere that you specify a revision number or revision
- keyword, you can also specify a date by specifying the date
+ keyword, you can also specify a date
inside curly braces {}. You can even access
a range of changes in the repository using both dates and
revisions together!
@@ -378,7 +378,7 @@
While you can certainly check out a working copy with the
URL of the repository as the only argument, you can also specify
a directory after your repository URL. This places your working
- copy into the new directory that you name. For example:
+ copy in the new directory that you name. For example:
$ svn checkout http://svn.collab.net/repos/svn/trunk subv
@@ -636,7 +636,7 @@
become a child of its parent directory. Note that if
foo is a directory, everything
underneath foo will be scheduled
- for addition. If you only want to schedule
+ for addition. If you only want to add
foo itself, pass the
()
switch.
@@ -917,7 +917,7 @@
might have a file in the repository, but you removed
the file and created a directory in its place, without
using the svn delete or
- svn add commands.
+ svn add command.
@@ -1259,8 +1259,8 @@
from the repository. The G
stands for merGed, which
means that the file had local changes to begin with, but the
- changes coming from the repository didn't overlap in any
- way.
+ changes coming from the repository didn't overlap with the local
+ changes.
But the C stands for
conflict. This means that the changes from the server overlapped
@@ -1703,7 +1703,7 @@
svn log
- To find out information about the history of a file or
+ To find information about the history of a file or
directory, use the svn log
command. svn log will provide you with a
record of who made changes to a file or directory, at what
@@ -1799,12 +1799,12 @@
supply no path, Subversion uses the current working
directory as the default target. As a result, if you're
operating in a subdirectory of your working copy and attempt
- to log a revision in which neither that directory nor any of
- its children was changed, Subversion will give you an empty
- log. If you want to see what changed in that revision, try
- pointing svn log directly at the top-most
- URL of your repository, as in svn log -r 2
- http://svn.collab.net/repos/svn.
+ to see the log of a revision in which neither that directory
+ nor any of its children was changed, Subversion will show you
+ an empty log. If you want to see what changed in that
+ revision, try pointing svn log directly at
+ the top-most URL of your repository, as in svn log -r
+ 2 http://svn.collab.net/repos/svn.
@@ -2047,12 +2047,13 @@
When Subversion modifies your working copy (or any
information within .svn), it tries to do
- so as safely as possible. Before changing anything, it writes
- its intentions to a log file, executes the commands in the log
- file, then removes the log file (this is similar in design to
- a journaled filesystem). If a Subversion operation is
- interrupted (if the process is killed, or if the machine
- crashes, for example), the log files remain on disk. By
+ so as safely as possible. Before changing the working copy,
+ Subversion writes its intentions to a log file. Next it executes
+ the commands in the log file to apply the requested change.
+ Finally, Subversion removes the log file. Architecturally, this
+ is similar to a journaled filesystem). If a Subversion
+ operation is interrupted (if the process is killed, or if the
+ machine crashes, for example), the log files remain on disk. By
re-executing the log files, Subversion can complete the
previously started operation, and your working copy can get
itself back into a consistent state.
Index: ch05.xml
===================================================================
--- ch05.xml (revision 11207)
+++ ch05.xml (working copy)
@@ -369,7 +369,7 @@
used by a single server process running as one
user—such as Apache's httpd or
svnserve (see )— rather than accessing it as
+ linkend="svn-ch-6"/>)—rather than accessing it as
many different users via file:/// or
svn+ssh:// URLs. If using a Berkeley DB
repository directly as multiple users, be sure to read Happily, the Subversion client has a remedy for this: a
built-in system for caching authentication credentials on
- disk. By default, whenever the commandline client
+ disk. By default, whenever the command-line client
successfully authenticates itself to a server, it saves the
credentials in the user's private runtime configuration
area—in ~/.subversion/auth/ on
@@ -346,7 +346,7 @@
Check whether the user specified any credentials as
- commandline options, via
+ command-line options, via
and/or . If not, or if these
options fail to authenticate successfully, then
@@ -1284,7 +1284,7 @@
certifying authority (CA). If
OpenSSL is unable to automatically trust the CA, or if some
other problem occurs (such as an expired certificate or
- hostname mismatch), the Subversion commandline client will
+ hostname mismatch), the Subversion command-line client will
ask you whether you want to trust the server certificate
anyway:
@@ -1358,7 +1358,7 @@
Subversion, it must be in PKCS#12 format, which is a
portable standard. Most web browsers are already able to
import and export certificates in that format. Another
- option is to use the OpenSSL commandline tools to convert
+ option is to use the OpenSSL command-line tools to convert
existing certificates into PKCS#12.
Again, the runtime servers file
Index: ch09.xml
===================================================================
--- ch09.xml (revision 11207)
+++ ch09.xml (working copy)
@@ -3580,7 +3580,7 @@
Sometimes an administrator might change the "base
- location" of your repository — in other words,
+ location" of your repository—in other words,
the contents of the repository doesn't change, but the
main URL used to reach the root of the repository does.
For example, the hostname may change, or the URL schema,