[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Book: split up compound words

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-10-21 19:10:26 CEST

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&mdash;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 &gt; 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 &gt; 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&mdash;much
+ <para>By default, the dump file will be quite large&mdash;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&mdash;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&mdash;and
         restoration from&mdash;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&mdash;an unversioned, modifiable
         property&mdash;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 &gt; 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&mdash;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>&mdash;a
- location in the logfiles known not to be corrupt&mdash;and
+ location in the log files known not to be corrupt&mdash;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&mdash;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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.