On Oct 21, 2004, at 12:10 PM, Julian Foad wrote:
> What do the book authors think of this? (I know people will say, "But
> I think of logfile as a single word.")
Actually, I prefer dumpfile, but for a different reason: My mind parses
"dumpfile" as a noun, and, unless the surrounding context is
*absolutely* straightforward, "dump file" is parsed as "verb, noun".
So -0 from me. I prefer *file.
> - 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 21 20:00:53 2004