[PATCH] Various svnbook fixes
Øyvind A. Holm
sunny at sunbase.org
Sat Jul 9 22:05:07 CDT 2005
I’ve had a working copy with lots of small fixes to the book lying
around for ages, with more small tweaks added over time, so maybe it’s
about time I pass it on. No word wrapping is done to make the patch
cleaner. There is no formal log message in this stage of the review,
it’s much less work to sort that out afterwards when the patch has been
filtered a bit. It’s only trivial changes anyway. But some explanation
can be done:
* CVS hasn’t used RCS as a backend in years.
Index: src/en/book/appa.xml
===================================================================
--- src/en/book/appa.xml (revision 1533)
+++ src/en/book/appa.xml (working copy)
@@ -25,7 +25,7 @@
<title>Revision Numbers Are Different Now</title>
<para>In CVS, revision numbers are per-file. This is because CVS
- uses RCS as a backend; each file has a corresponding RCS file in
+ previously used RCS as a backend; each file has a corresponding RCS file in
the repository, and the repository is roughly laid out according
to the structure of your project tree.</para>
* Specify that it’s only Berkeley DB databases which can’t live on a
network disk. fsfs should have no problems with it?
Index: src/en/book/ch01.xml
===================================================================
--- src/en/book/ch01.xml (revision 1533)
+++ src/en/book/ch01.xml (working copy)
@@ -453,9 +453,11 @@
<para>This command creates a new directory
<filename>/path/to/repos</filename> which contains a Subversion
- repository. Make sure that this directory lives on a local
+ repository. If you are creating a Berkeley DB repository (i.e.
+ using the <option>--fs-type=bdb</option> option with the
+ <command>svnadmin</command> command), make sure that this directory lives on a local
disk, <emphasis>not</emphasis> a network share. This new
* Avoid wordwrapping.
Index: src/en/book/ch04.xml
===================================================================
--- src/en/book/ch04.xml (revision 1533)
+++ src/en/book/ch04.xml (working copy)
[...]
notice that they're unrelated and first attempt to delete
the old file, then add the new file; you would see a
- <literal>D foo.c</literal> followed by a <literal>A
- foo.c</literal>.</para>
+ <literal>D foo.c</literal> followed by a
+ <literal>A foo.c</literal>.</para>
e6f635b6d86bb49f223fdfc204e10d91 r1533-tweaks.patch
-- sunny256
-------------- next part --------------
Index: src/en/book/appa.xml
===================================================================
--- src/en/book/appa.xml (revision 1533)
+++ src/en/book/appa.xml (working copy)
@@ -25,7 +25,7 @@
<title>Revision Numbers Are Different Now</title>
<para>In CVS, revision numbers are per-file. This is because CVS
- uses RCS as a backend; each file has a corresponding RCS file in
+ previously used RCS as a backend; each file has a corresponding RCS file in
the repository, and the repository is roughly laid out according
to the structure of your project tree.</para>
Index: src/en/book/ch01.xml
===================================================================
--- src/en/book/ch01.xml (revision 1533)
+++ src/en/book/ch01.xml (working copy)
@@ -453,9 +453,11 @@
<para>This command creates a new directory
<filename>/path/to/repos</filename> which contains a Subversion
- repository. Make sure that this directory lives on a local
+ repository. If you are creating a Berkeley DB repository (i.e.
+ using the <option>--fs-type=bdb</option> option with the
+ <command>svnadmin</command> command), make sure that this directory lives on a local
disk, <emphasis>not</emphasis> a network share. This new
- directory mainly contains a collection of Berkeley DB database
+ directory mainly contains a collection of database
files. You won't see your versioned files if you peek inside.
For more information about repository creation and maintenance,
see <xref linkend="svn.reposadmin"/>.</para>
Index: src/en/book/ch02.xml
===================================================================
--- src/en/book/ch02.xml (revision 1533)
+++ src/en/book/ch02.xml (working copy)
@@ -54,7 +54,7 @@
example, a client can ask historical questions like, <quote>What
did this directory contain last Wednesday?</quote> or <quote>Who
was the last person to change this file, and what changes did
- they make?</quote> These are the sorts of questions that are at
+ he make?</quote> These are the sorts of questions that are at
the heart of any <firstterm>version control system</firstterm>:
systems that are designed to record and track changes to data
over time.
@@ -530,8 +530,8 @@
number selects an entire tree, a particular state of the
repository after some committed change. Another way to
think about it is that revision N represents the state of
- the repository filesystem after the Nth commit. When a
- Subversion user talks about <quote>revision 5 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
<quote><filename>foo.c</filename> as it appears in revision 5.</quote>
Notice that in general, revisions N and M of a file do
Index: src/en/book/ch03.xml
===================================================================
--- src/en/book/ch03.xml (revision 1533)
+++ src/en/book/ch03.xml (working copy)
@@ -178,7 +178,7 @@
$ svn diff --revision HEAD
# compares your working file (with local mods) to the latest version
-# in the repository.
+# in the repository
$ svn diff --revision BASE:HEAD foo.c
# compares your <quote>pristine</quote> foo.c (no local mods) with the
@@ -1713,7 +1713,7 @@
<varlistentry>
<term><command>svn log</command></term>
<listitem>
- <para>Shows you broad information: log messages attached
+ <para>Shows you broad information: log messages with date and author information attached
to revisions, and which paths changed in each
revision.</para>
</listitem>
@@ -1751,10 +1751,10 @@
<sect2 id="svn.tour.history.log">
<title><command>svn log</command></title>
- <para>To find information about the history of a file or
+ <para>To find information about the history of a file, symlink or
directory, use the <command>svn log</command>
command. <command>svn log</command> will provide you with a
- record of who made changes to a file or directory, at what
+ record of who made changes to this file, symlink or directory, at what
revision it changed, the time and date of that revision, and,
if it was provided, the log message that accompanied the
commit.</para>
Index: src/en/book/ch04.xml
===================================================================
--- src/en/book/ch04.xml (revision 1533)
+++ src/en/book/ch04.xml (working copy)
@@ -644,7 +644,7 @@
tree-changes.</para>
</footnote>
The <command>svn merge</command> command, however, can express
- tree-changes by directly applying them to your working
+ changes in tree structure and properties by directly applying them to your working
copy.</para>
</sidebar>
@@ -885,7 +885,7 @@
Somebody can then run <command>svn log -r9238</command> to
read about the exact changeset which fixed the bug, and run
<command>svn diff -r9237:9238</command> to see the patch
- itself. And Subversion's merge command also uses revision
+ itself. And Subversion's <command>merge</command> command also uses revision
numbers. You can merge specific changesets from one branch
to another by naming them in the merge arguments:
<command>svn merge -r9237:9238</command> would merge
@@ -1010,18 +1010,18 @@
ancestry, while the latter command is quite sensitive to it.
For example, if you asked <command>svn diff</command> to
compare revisions 99 and 102 of <filename>foo.c</filename>,
- you would see line-based diffs; the diff command is blindly
+ you would see line-based diffs; the <command>diff</command> command is blindly
comparing two paths. But if you asked <command>svn
merge</command> to compare the same two objects, it would
notice that they're unrelated and first attempt to delete
the old file, then add the new file; you would see a
- <literal>D foo.c</literal> followed by a <literal>A
- foo.c</literal>.</para>
+ <literal>D foo.c</literal> followed by a
+ <literal>A foo.c</literal>.</para>
<para>Most merges involve comparing trees that are ancestrally
related to one another, and therefore <command>svn
merge</command> defaults to this behavior. Occasionally,
- however, you may want the merge command to compare two
+ however, you may want the <command>merge</command> command to compare two
unrelated trees. For example, you may have imported two
source-code trees representing different vendor releases of
a software project (see <xref linkend="svn.advanced.vendorbr"/>).
@@ -1036,7 +1036,7 @@
command, and it will behave just like <command>svn
diff</command>. (And conversely, the
<option>--notice-ancestry</option> option will cause
- <command>svn diff</command> to behave like the merge
+ <command>svn diff</command> to behave like the <command>merge</command>
command.)</para>
</sect3>
@@ -1319,7 +1319,7 @@
directory, it may be gone from the <literal>HEAD</literal>
revision, but the object still exists in earlier revisions.
One of the most common questions new users ask is, <quote>How
- do I get my old file or directory back?</quote></para>
+ do I get my old file or directory back?</quote>.</para>
<para>The first step is to define exactly <emphasis
role="bold">which</emphasis> item you're trying to resurrect.
@@ -1737,7 +1737,7 @@
<para>Have you noticed that the output of <command>svn
switch</command> and <command>svn update</command> look the
- same? The switch command is actually a superset of the
+ same? The <command>switch</command> command is actually a superset of the
update command.</para>
<para>When you run <command>svn update</command>, you're asking
@@ -1745,7 +1745,7 @@
and then sends a description of the differences back to the
client. The only difference between <command>svn
switch</command> and <command>svn update</command> is that the
- update command always compares two identical paths.</para>
+ <command>update</command> command always compares two identical paths.</para>
<para>That is, if your working copy is a mirror of
<filename>/calc/trunk</filename>, then <command>svn
@@ -1910,7 +1910,7 @@
changes made to your working copy, and you'd like a
collaborator to see them. Instead of running <command>svn
diff</command> and sending a patch file (which won't capture
- tree changes), you can instead use <command>svn copy</command>
+ tree changes, symlink changes or changes in properties), you can instead use <command>svn copy</command>
to <quote>upload</quote> your working copy to a private area
of the repository. Your collaborator can then either checkout
a verbatim copy of your working copy, or use <command>svn
@@ -1983,8 +1983,8 @@
working copies. If a user has a working copy of a particular
repository directory, your <command>svn move</command>
operation might remove the path from the latest revision.
- When the user next runs <command>svn update</command>, they'll
- be told that their working copy represents a path that no
+ When the user next runs <command>svn update</command>, she will
+ be told that her working copy represents a path that no
longer exists, and the user will be forced to <command>svn
switch</command> to the new location.
</para>
@@ -2039,7 +2039,7 @@
branch. In software development, though, it's also common to
have two <quote>main</quote> branches running side-by-side for
very long periods. For example, suppose it's time to release
- a stable <filename>calc</filename> project to the public, and
+ a stable version of the <filename>calc</filename> project to the public, and
you know it's going to take a couple of months to shake bugs
out of the software. You don't want people to add new
features to the project, but you don't want to tell all
Index: src/en/book/ch05.xml
===================================================================
--- src/en/book/ch05.xml (revision 1533)
+++ src/en/book/ch05.xml (working copy)
@@ -1120,7 +1120,7 @@
other queries, displaying subsets of bits of information
we've mentioned previously, reporting which paths were
modified in a given revision or transaction, showing textual
- and property differences made to files and directories, and
+ and property differences made to files, symlinks and directories, and
so on. The following is a brief description of the current
list of subcommands accepted by <command>svnlook</command>,
and the output of those subcommands:</para>
@@ -1772,7 +1772,7 @@
<para>Perhaps the most commonly used of
<command>svnadmin</command>'s subcommands is
- <literal>setlog</literal>. When a transaction is committed to
+ <command>setlog</command>. When a transaction is committed to
the repository and promoted to a revision, the descriptive log
message associated with that new revision (and provided by the
user) is stored as an unversioned property attached to the
@@ -1788,7 +1788,7 @@
linkend="svn.reposadmin.create.hooks"/>) to accept changes to this log
message after the commit is finished, then the user can
<quote>fix</quote> her log message remotely using the
- <command>svn</command> program's <literal>propset</literal>
+ <command>svn</command> program's <command>propset</command>
command (see <xref linkend="svn.ref"/>). However, because of
the potential to lose information forever, Subversion
repositories are not, by default, configured to allow changes
@@ -1842,7 +1842,7 @@
them.</para>
<para>You can use <command>svnadmin</command>'s
- <literal>lstxns</literal> command to list the names of the
+ <command>lstxns</command> command to list the names of the
currently outstanding transactions.</para>
<screen>
@@ -1862,7 +1862,7 @@
removal! If so, the transaction's name can be passed to
<command>svnadmin rmtxns</command>, which will perform the
cleanup of the transaction. In fact, the
- <literal>rmtxns</literal> subcommand can take its input
+ <command>rmtxns</command> subcommand can take its input
directly from the output of <literal>lstxns</literal>!</para>
<screen>
@@ -2020,7 +2020,7 @@
equal to the size of the original data, it only takes up
enough space to say, <quote>I look just like this other
piece of data over here, except for the following couple of
- changes.</quote> Specifically, each time a new version of a
+ changes</quote>. Specifically, each time a new version of a
file is committed to the repository, Subversion encodes the
previous version (actually, several previous versions) as a
delta against the new version. The result is that most of
@@ -2237,7 +2237,7 @@
requested range of revisions. Note that <command>svnadmin
dump</command> is reading revision trees from the repository
just like any other <quote>reader</quote> process would
- (<command>svn checkout</command>, for example.) So it's safe
+ (<command>svn checkout</command>, for example). So it's safe
to run this command at any time.</para>
<para>The other subcommand in the pair, <command>svnadmin
@@ -2451,7 +2451,7 @@
<command>cvs2svn</command> utility (see <xref
linkend="svn.forcvs.convert"/>) uses the dump format to represent the
contents of a CVS repository so that those contents can be
- moved in a Subversion repository.</para>
+ copied into a Subversion repository.</para>
</sect2>
Index: src/en/book/ch06.xml
===================================================================
--- src/en/book/ch06.xml (revision 1533)
+++ src/en/book/ch06.xml (working copy)
@@ -5,7 +5,7 @@
<para>A Subversion repository can be accessed simultaneously by
clients running on the same machine on which the repository
- resides using the <literal>file:///</literal> method. But the
+ resides using the <literal>file://</literal> method. But the
typical Subversion setup involves a single server machine being
accessed from clients on computers all over the office—or,
perhaps, all over the world.</para>
@@ -398,7 +398,7 @@
<para>If the client successfully authenticates by any of the
methods listed above, it will attempt to cache the credentials
on disk (unless the user has disabled this behavior, as
- mentioned earlier.)</para>
+ mentioned earlier).</para>
</sect2>
@@ -512,7 +512,7 @@
repository directly needs to have proper read and write
permissions on the entire repository. If you're not
careful, this can lead to a number of headaches, especially
- if you're using a BerkeleyDB database rather than FSFS. Be
+ if you're using a Berkeley DB database rather than FSFS. Be
sure to read <xref linkend="svn.serverconfig.multimethod"/>.</para>
<para>Secondly, when configuring <command>svnserve</command>,
@@ -645,7 +645,7 @@
client displays it in the authentication prompt, and uses it
as a key (along with the server's hostname and port) for
caching credentials on disk (see <xref
- linkend="svn.serverconfig.netmodel.credcache"/>.) The
+ linkend="svn.serverconfig.netmodel.credcache"/>). The
<literal>password-db</literal> variable points to a separate
file that contains a list of usernames and passwords, using
the same familiar format. For example:</para>
@@ -823,7 +823,7 @@
<para>You'd think that the story of SSH tunneling would end
here, but it doesn't. Subversion allows you to create custom
tunnel behaviors in your run-time <filename>config</filename>
- file (see <xref linkend="svn.advanced.confarea"/>.) For example,
+ file (see <xref linkend="svn.advanced.confarea"/>). For example,
suppose you want to use RSH instead of SSH. In the
<literal>[tunnels]</literal> section of your
<filename>config</filename> file, simply define it like
@@ -842,7 +842,7 @@
scenes. If you include a username in the URL (for example,
<literal>svn+rsh://username@host/path</literal>) the client
will also include that in its command (<command>rsh
- username at host svnserve -t</command>.) But you can define new
+ username at host svnserve -t</command>). But you can define new
tunneling schemes to be much more clever than that:</para>
<screen>
@@ -1016,7 +1016,7 @@
available to clients via the WebDAV/DeltaV protocol, which is an
extension to HTTP 1.1
(see <systemitem class="url">http://www.webdav.org/</systemitem>
- for more information.) This protocol takes the ubiquitous HTTP
+ for more information). This protocol takes the ubiquitous HTTP
protocol that is the core of the World Wide Web, and adds
writing—specifically, versioned
writing—capabilities. The result is a standardized,
@@ -1497,7 +1497,7 @@
will be cached in your private run-time
<filename>auth/</filename> area in just the same way your
username and password are cached (see <xref
- linkend="svn.serverconfig.netmodel.credcache"/>.) If cached, Subversion will
+ linkend="svn.serverconfig.netmodel.credcache"/>). If cached, Subversion will
automatically remember to trust this certificate in future
negotiations.</para>
@@ -2248,7 +2248,7 @@
</screen>
<para>Another common problem is often encountered on Unix-like
- systems. As a repository is used, BerkeleyDB occasionally
+ systems. As a repository is used, Berkeley DB occasionally
creates new log files to journal its actions. Even if the
repository is wholly owned by the <command>svn</command> group,
these newly created files won't necessarily be owned by that
More information about the svnbook-dev
mailing list