What do the book authors think of this? (I know people will say, "But I
think of logfile as a single word.")
- Julian
Book: expand some jargon compound words.
Writing a jargon phrase such as "dump file" as a compound word ("dumpfile") is
common among those who use it often, but inappropriate in text aimed at a wide
audience.
* doc/book/book/ch01.xml
* doc/book/book/ch03.xml
* doc/book/book/ch05.xml
* doc/book/book/ch09.xml
Expand contracted forms of "stumbling-block", "back-reference", "bug fix",
"patch file", "dump file", "lock file", "log file".
Index: doc/book/book/ch01.xml
===================================================================
--- doc/book/book/ch01.xml (revision 11523)
+++ doc/book/book/ch01.xml (working copy)
@@ -377,7 +377,7 @@
<varlistentry>
<term>svndumpfilter</term>
<listitem>
- <para>A program for filtering Subversion repository dumpfile
+ <para>A program for filtering Subversion repository dump file
format streams.</para>
</listitem>
</varlistentry>
Index: doc/book/book/ch05.xml
===================================================================
--- doc/book/book/ch05.xml (revision 11526)
+++ doc/book/book/ch05.xml (working copy)
@@ -1327,14 +1327,14 @@
aren't careless about it, you can manually inspect and
modify it. Of course, the downside is that if you have two
years' worth of repository activity encapsulated in what is
- likely to be a very large dumpfile, it could take you a
+ likely to be a very large dump file, it could take you a
long, long time to manually inspect and modify it.</para>
<para>While it won't be the most commonly used tool at the
administrator's disposal, <command>svndumpfilter</command>
provides a very particular brand of useful
functionality—the ability to quickly and easily modify
- that dumpfile data by acting as a path-based filter. Simply
+ that dump file data by acting as a path-based filter. Simply
give it either a list of paths you wish to keep, or a list
of paths you wish to not keep, then pipe your repository
dump data through this filter. The result will be a
@@ -1411,7 +1411,7 @@
</screen>
<para>To get these three projects into their own repositories,
- we first make a dumpfile of the whole repository:</para>
+ we first make a dump file of the whole repository:</para>
<screen>
$ svnadmin dump /path/to/repos > repos-dumpfile
@@ -1423,9 +1423,9 @@
$
</screen>
- <para>Next, run that dumpfile through the filter, each time
+ <para>Next, run that dump file through the filter, each time
including only one of our top-level directories, and
- resulting in three new dumpfiles:</para>
+ resulting in three new dump files:</para>
<screen>
$ cat repos-dumpfile | svndumpfilter include calc > calc-dumpfile
@@ -1438,7 +1438,7 @@
</screen>
<para>At this point, you have to make a decision. Each of
- your dumpfiles will create a valid repository,
+ your dump files will create a valid repository,
but will preserve the paths exactly as they were in the
original repository. This means that even though you would
have a repository solely for your <literal>calc</literal>
@@ -1447,7 +1447,7 @@
your <filename>trunk</filename>, <filename>tags</filename>,
and <filename>branches</filename> directories to live in the
root of your repository, you might wish to edit your
- dumpfiles, tweaking the <literal>Node-path</literal> and
+ dump files, tweaking the <literal>Node-path</literal> and
<literal>Copyfrom-path</literal> headers to no longer have
that first <filename>calc/</filename> path component. Also,
you'll want to remove the section of dump data that creates
@@ -1472,7 +1472,7 @@
</warning>
<para>All that remains now is to create your three new
- repositories, and load each dumpfile into the right
+ repositories, and load each dump file into the right
repository:</para>
<screen>
@@ -1538,7 +1538,7 @@
useful, and a huge timesaver, there are unfortunately a
couple of gotchas. First, this utility is overly sensitive
to path semantics. Pay attention to whether paths in your
- dumpfile are specified with or without leading slashes.
+ dump file are specified with or without leading slashes.
You'll want to look at the <literal>Node-path</literal> and
<literal>Copyfrom-path</literal> headers.</para>
@@ -1552,7 +1552,7 @@
include leading slashes in the paths you pass to
<command>svndumpfilter include</command> and
<command>svndumpfilter exclude</command> (and if they don't,
- you shouldn't). Further, if your dumpfile has an inconsistent
+ you shouldn't). Further, if your dump file has an inconsistent
usage of leading slashes for some reason,
<footnote>
<para>While <command>svnadmin dump</command> has a
@@ -2292,19 +2292,19 @@
$ svnadmin dump myrepos | svnadmin load newrepos
</screen>
- <para>By default, the dumpfile will be quite large—much
+ <para>By default, the dump file will be quite large—much
larger than the repository itself. That's because every
version of every file is expressed as a full text in the
- dumpfile. This is the fastest and simplest behavior, and nice
+ dump file. This is the fastest and simplest behavior, and nice
if you're piping the dump data directly into some other
process (such as a compression program, filtering program, or
- into a loading process). But if you're creating dumpfile for
+ into a loading process). But if you're creating a dump file for
longer-term storage, you'll likely want to save disk space by
using the <option>--deltas</option> switch. With this option,
successive revisions of files will be output as compressed,
binary differences—just as file revisions are stored in
a repository. This option is slower, but results in a
- dumpfile much closer in size to the original
+ dump file much closer in size to the original
repository.</para>
<para>We mentioned previously that <command>svnadmin
@@ -2384,7 +2384,7 @@
several different repositories into a single repository. By
using the <option>--parent-dir</option> option of <command>svnadmin
load</command>, you can specify a new virtual root directory
- for the load process. That means if you have dumpfiles for
+ for the load process. That means if you have dump files for
three repositories, say <filename>calc-dumpfile</filename>,
<filename>cal-dumpfile</filename>, and
<filename>ss-dumpfile</filename>, you can first create a new
@@ -2408,7 +2408,7 @@
$
</screen>
- <para>Lastly, load the individual dumpfiles into their
+ <para>Lastly, load the individual dump files into their
respective locations in the new repository:</para>
<screen>
@@ -2528,7 +2528,7 @@
convenient to already have half of that process (the dump
part) finished. Unfortunately, the creation of—and
restoration from—incremental backups takes longer, as
- each commit is effectively replayed into either the dumpfile
+ each commit is effectively replayed into either the dump file
or the repository.</para>
<para>In either backup scenario, repository administrators need
Index: doc/book/book/ch09.xml
===================================================================
--- doc/book/book/ch09.xml (revision 11526)
+++ doc/book/book/ch09.xml (working copy)
@@ -3851,7 +3851,7 @@
<term><option>--parent-dir
<replaceable>DIR</replaceable></option></term>
<listitem>
- <para>When loading a dumpfile, root paths at
+ <para>When loading a dump file, root paths at
<replaceable>DIR</replaceable> instead of
<filename>/</filename>.</para>
</listitem>
Index: doc/book/book/ch03.xml
===================================================================
--- doc/book/book/ch03.xml (revision 11526)
+++ doc/book/book/ch03.xml (working copy)
@@ -274,7 +274,7 @@
</screen>
<para>Users should be aware of a subtlety that can become quite
- a stumblingblock when dealing with dates in Subversion. Since
+ a stumbling-block when dealing with dates in Subversion. Since
the timestamp of a revision is stored as a property of the
revision—an unversioned, modifiable
property—revision timestamps can be changed to represent
Index: doc/book/book/ch03.xml
===================================================================
--- doc/book/book/ch03.xml (revision 11526)
+++ doc/book/book/ch03.xml (working copy)
@@ -1129,7 +1129,7 @@
$ svn diff > patchfile
</screen>
- <para>You could, for example, email the patchfile to another
+ <para>You could, for example, email the patch file to another
developer for review or testing prior to commit.</para>
</sect3>
Index: doc/book/book/appa.xml
===================================================================
--- doc/book/book/appa.xml (revision 11523)
+++ doc/book/book/appa.xml (working copy)
@@ -6,7 +6,7 @@
<para>This appendix is a guide for CVS users new to Subversion.
It's essentially a list of differences between the two systems
as <quote>viewed from 10,000 feet</quote>. For each section, we
- provide backreferences to relevant chapters when
+ provide back-references to relevant chapters when
possible.</para>
<para>Although the goal of Subversion is to take over the current
Index: doc/book/book/ch00.xml
===================================================================
--- doc/book/book/ch00.xml (revision 11523)
+++ doc/book/book/ch00.xml (working copy)
@@ -634,7 +634,7 @@
</varlistentry>
<varlistentry>
- <term>Optimizations and bugfixes</term>
+ <term>Optimizations and bug fixes</term>
<listitem>
<para>The <command>svn checkout</command>, <command>svn
update</command>, <command>svn status</command>, and
Index: doc/book/book/ch04.xml
===================================================================
--- doc/book/book/ch04.xml (revision 11523)
+++ doc/book/book/ch04.xml (working copy)
@@ -891,7 +891,7 @@
time. Suppose several days have passed, and many changes have
happened on both the trunk and your private branch. Suppose
that you've finished working on your private branch; the
- feature or bugfix is finally complete, and now you want to
+ feature or bug fix is finally complete, and now you want to
merge all of your branch changes back into the trunk for
others to enjoy.</para>
@@ -991,7 +991,7 @@
<para>For example, suppose you decide to keep working on your
branch for another week, in order to complete an enhancement
- to your original feature or bugfix. The repository's
+ to your original feature or bug fix. The repository's
<literal>HEAD</literal> revision is now 480, and you're ready
to do another merge from your private branch to the trunk.
But as discussed in <xref linkend="svn-ch-4-sect-3.2"/>, you
@@ -1489,7 +1489,7 @@
<filename>calc</filename> example: suppose it contains a
number of subdirectories and many more files. In the course
of your work, you may decide that you need to create a working
- copy that is designed to have specific features and bugfixes.
+ copy that is designed to have specific features and bug fixes.
You can accomplish this by selectively backdating files or
directories to particular revisions (using <command>svn update
-r</command> liberally), or by switching files and directories
@@ -1672,10 +1672,10 @@
<para>And now developers are free to continue adding
cutting-edge (or experimental) features to
<filename>/calc/trunk</filename>, and you can declare a
- project policy that only bugfixes are to be committed to
+ project policy that only bug fixes are to be committed to
<filename>/calc/branches/stable-1.0</filename>. That is, as
people continue to work on the trunk, a human selectively
- ports bugfixes over to the stable branch. Even after the
+ ports bug fixes over to the stable branch. Even after the
stable branch has shipped, you'll probably continue to
maintain the branch for a long time—that is, as long
as you continue to support that release for customers.</para>
Index: doc/book/book/appb.xml
===================================================================
--- doc/book/book/appb.xml (revision 11526)
+++ doc/book/book/appb.xml (working copy)
@@ -48,9 +48,9 @@
access your data. Berkeley DB is a journaling system, meaning
that it logs everything it is about to do before it does so. If
your process is interrupted (e.g. by a kill signal or segfault),
- then a lockfile is left behind, along with a logfile describing
+ then a lock file is left behind, along with a log file describing
unfinished business. Any other process that attempts to
- access the database will just hang, waiting for the lockfile
+ access the database will just hang, waiting for the lock file
to disappear. To awaken your repository, you need to ask
Berkeley DB to either finish the work, or rewind the
database to a previous state that is known to be
@@ -85,7 +85,7 @@
journaling mechanism to perform all actions. That is, it
logs everything it is about to do before it does so. If
<command>svn</command> is interrupted while performing an
- action, then one or more lockfiles are left behind, along
+ action, then one or more lock files are left behind, along
with log files describing the unfinished
actions. (<command>svn status</command> will show an
<literal>L</literal> next to locked directories.)</para>
Index: doc/book/book/ch05.xml
===================================================================
--- doc/book/book/ch05.xml (revision 11526)
+++ doc/book/book/ch05.xml (working copy)
@@ -320,15 +320,15 @@
<para>Berkeley DB is also a very reliable database system.
Subversion uses Berkeley DB's logging facilities, which
- means that the database first writes to on-disk logfiles a
+ means that the database first writes to on-disk log files a
description of any modifications it is about to make, and
then makes the modification itself. This is to ensure that
if anything goes wrong, the database system can back up to
a previous <firstterm>checkpoint</firstterm>—a
- location in the logfiles known not to be corrupt—and
+ location in the log files known not to be corrupt—and
replay transactions until the data is restored to a usable
state. See <xref linkend="svn-ch-5-sect-3.3"/> for more
- about Berkeley DB logfiles.</para>
+ about Berkeley DB log files.</para>
<para>But every rose has its thorn, and so we must note some
known limitations of Berkeley DB. First, Berkeley DB
@@ -1964,18 +1964,18 @@
data that be cleaned up or reclaimed.</para>
<para>Until recently, the largest offender of disk space usage
- with respect to Subversion repositories was the logfiles to
+ with respect to Subversion repositories was the log files to
which Berkeley DB performs its pre-writes before modifying
the actual database files. These files capture all the
actions taken along the route of changing the database from
one state to another—while the database files reflect
- at any given time some state, the logfiles contain all the
+ at any given time some state, the log files contain all the
many changes along the way between states. As such, they
can start to accumulate quite rapidly.</para>
<para>Fortunately, beginning with the 4.2 release of Berkeley
DB, the database environment has the ability to remove its
- own unused logfiles without any external procedures. Any
+ own unused log files without any external procedures. Any
repositories created using an <command>svnadmin</command>
which is compiled against Berkeley DB version 4.2 or greater
will be configured for this automatic log file removal. If
@@ -2002,7 +2002,7 @@
longer in use by Berkeley DB, and then remove them from disk
to conserve space. Use the <command>svnadmin
list-unused-dblogs</command> command to list the unused
- logfiles:</para>
+ log files:</para>
<screen>
$ svnadmin list-unused-dblogs /path/to/repos
Index: doc/book/book/ch06.xml
===================================================================
--- doc/book/book/ch06.xml (revision 11523)
+++ doc/book/book/ch06.xml (working copy)
@@ -1984,13 +1984,13 @@
<para>Another common problem is often encountered on Unix-like
systems. As a repository is used, BerkeleyDB occasionally
- creates new logfiles to journal its actions. Even if the
+ 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
same group, which then creates more permissions problems for
your users. A good workaround is to set the group SUID bit on
the repository's <filename>db</filename> directory. This causes
- all newly-created logfiles to have the same group owner as the
+ all newly-created log files to have the same group owner as the
parent directory.</para>
<para>Once you've jumped through these hoops, your repository
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 21 19:11:24 2004