[svnbook commit] r3207 - trunk/src/en/book
cmpilato
noreply at red-bean.com
Fri Jul 25 00:16:27 CDT 2008
Author: cmpilato
Date: Fri Jul 25 00:16:27 2008
New Revision: 3207
Log:
Port r101466 from the O'Reilly production repository, whose log
message read thusly:
Finish what I began in r101464, whose log message read partially as
such:
In VCWS 2e, begin the work of distinguishing between programs,
commands, and subcommands refered to informationally (using <command>)
and same invocations of those at a command-line (using <userinput>).
To establish a clear policy, this meant rewording some sections to
avoid referring ambiguously to a subcommand plus a particular
command-line option. Sometimes the resolution was to create a
command-line invocable string; sometimes it was to refer to the option
in the prose around the named subcommand.
While here, fixup some other obvious problems such as missing or
misplaced <replaceable> tags.
* src/en/book/ch01-fundamental-concepts.xml,
* src/en/book/ch04-branching-and-merging.xml,
* src/en/book/ch08-embedding-svn.xml
Modified:
trunk/src/en/book/ch01-fundamental-concepts.xml
trunk/src/en/book/ch04-branching-and-merging.xml
trunk/src/en/book/ch08-embedding-svn.xml
Modified: trunk/src/en/book/ch01-fundamental-concepts.xml
==============================================================================
--- trunk/src/en/book/ch01-fundamental-concepts.xml (original)
+++ trunk/src/en/book/ch01-fundamental-concepts.xml Fri Jul 25 00:16:27 2008
@@ -533,7 +533,7 @@
in</firstterm>) changes to the repository.</para>
<para>To publish your changes to others, you can use
- Subversion's <command>commit</command> command.</para>
+ Subversion's <command>svn commit</command> command.</para>
<screen>
$ svn commit button.c -m "Fixed a typo in button.c."
@@ -558,7 +558,7 @@
<para>To bring her project up to date, Sally can ask Subversion
to <firstterm>update</firstterm> her working copy, by using
- the <command>update</command> command. This will incorporate
+ the <command>svn update</command> command. This will incorporate
your changes into her working copy, as well as any others that
have been committed since she checked it out.</para>
@@ -860,7 +860,7 @@
of revisions. Even if you're the only person using the
repository, you will still see this phenomenon. To examine
your mixture of working revisions, use the <command>svn
- status --verbose</command> command (see <xref
+ status</command> command with the <option>--verbose</option> option (see <xref
linkend="svn.tour.cycle.examine.status"/> for more
information.)</para>
Modified: trunk/src/en/book/ch04-branching-and-merging.xml
==============================================================================
--- trunk/src/en/book/ch04-branching-and-merging.xml (original)
+++ trunk/src/en/book/ch04-branching-and-merging.xml Fri Jul 25 00:16:27 2008
@@ -236,8 +236,8 @@
sharing data are hidden from the user, who simply sees
copies of trees. The main point here is that copies are
cheap, both in time and space. If you create a branch
- entirely within the repository (by running <command>svn copy
- URL1 URL2</command>), it's a quick, constant-time operation.
+ entirely within the repository (by running <userinput>svn copy
+ <replaceable>URL1</replaceable> <replaceable>URL2</replaceable></userinput>), it's a quick, constant-time operation.
Make branches as often as you want.</para>
</sidebar>
@@ -501,14 +501,14 @@
revision numbers to refer to particular patches that fix
bugs—for example,
<quote>this issue was fixed by r9238.</quote> Somebody
- can then run <command>svn log -r 9238</command> to read about
+ can then run <userinput>svn log -r 9238</userinput> to read about
the exact changeset that fixed the bug, and run
- <command>svn diff -c 9238</command> to see the patch itself.
+ <userinput>svn diff -c 9238</userinput> to see the patch itself.
And (as you'll see shortly)
- Subversion's <command>merge</command> command is able to use
+ Subversion's <command>svn merge</command> command is able to use
revision numbers. You can merge specific changesets from one
branch to another by naming them in the merge
- arguments: <command>svn merge -c 9238</command> would merge
+ arguments: passing <userinput>-c 9238</userinput> to <command>svn merge</command> would merge
changeset r9238 into your working copy.</para>
</sect2>
@@ -548,8 +548,8 @@
U integer.c
</screen>
- <para>This basic syntax—<command>svn merge
- URL</command>—tells Subversion to merge all recent
+ <para>This basic syntax—<userinput>svn merge
+ <replaceable>URL</replaceable></userinput>—tells Subversion to merge all recent
changes from the URL to the current working directory (which
is typically the root of your working copy.) After running
the prior example, your branch working copy now contains new
@@ -583,7 +583,7 @@
no <emphasis>syntactic</emphasis> conflicts doesn't mean there
aren't any <emphasis>semantic</emphasis> conflicts!) If you
encounter serious problems, you can always abort the local
- changes by running <command>svn revert . -R</command> (which
+ changes by running <userinput>svn revert . -R</userinput> (which
will undo all local modifications) and start a
long <quote>what's going on?</quote> discussion with your
collaborators. If things look good, however, then you can
@@ -919,8 +919,8 @@
<tip>
<para>After performing a merge operation, but before committing
- the results of the merge, you can use <command>svn diff
- --depth=empty /path/to/merge/target</command> to see only
+ the results of the merge, you can use <userinput>svn diff
+ --depth=empty <replaceable>/path/to/merge/target</replaceable></userinput> to see only
the changes to the immediate target of your merge. If your
merge target was a directory, only property differences will
be displayed. This is a handy way to see the changes to the
@@ -935,7 +935,7 @@
modifications to your working copy—but we've already
stressed that you shouldn't be merging into such an
environment.) If you don't like the results of the merge,
- simply <command>svn revert . -R</command> the changes from
+ simply run <userinput>svn revert . -R</userinput> to revert the changes from
your working copy and retry the command with different
options. The merge isn't final until you
actually <command>svn commit</command> the results.</para>
@@ -1073,7 +1073,7 @@
<para>First, you might need to use <command>svn log</command> to
discover the exact coordinate pair you wish to resurrect. A
- good strategy is to run <command>svn log --verbose</command>
+ good strategy is to run <userinput>svn log --verbose</userinput>
in a directory that used to contain your deleted item. The
<option>--verbose</option> (<option>-v</option>) option shows
a list of all changed items in each revision; all you need to
@@ -1500,8 +1500,8 @@
<listitem>
<para><emphasis>Merging from foreign
repositories</emphasis>. While it's possible to run a
- command such as <command>svn merge -r 100:200
- http://svn.foreignproject.com/repos/trunk</command>, the
+ command such as <userinput>svn merge -r 100:200
+ <replaceable>http://svn.foreignproject.com/repos/trunk</replaceable></userinput>, the
resulting patch will also lack any historical merge
metadata. At time of writing, Subversion has no way of
representing different repository URLs within
@@ -1526,12 +1526,12 @@
a <quote>reverse patch</quote> as a way of rolling back
changes. If this technique is used to undo a change to a
object's personal history (e.g., commit r5 to the trunk,
- then immediately roll back r5 using <command>svn merge -c
- -5</command>), this sort of merge doesn't affect the
+ then immediately roll back r5 using <userinput>svn merge . -c
+ -5</userinput>), this sort of merge doesn't affect the
recorded mergeinfo.
<footnote><para>Interestingly, after rolling back a
revision like this, we wouldn't be able to re-apply
- the revision using <command>svn merge -c 5</command>,
+ the revision using <userinput>svn merge . -c 5</userinput>,
since the mergeinfo would already list r5 as being
applied. We would have to use
the <option>--ignore-ancestry</option> option to make
@@ -1602,7 +1602,7 @@
likely comparing the wrong two trees; they're the classic
sign of user error. When this happens, it's easy to
recursively revert all the changes created by the merge
- (<command>svn revert --recursive</command>), delete any
+ (<userinput>svn revert . --recursive</userinput>), delete any
unversioned files or directories left behind after the
revert, and rerun <command>svn merge</command> with
different arguments.</para>
@@ -1909,7 +1909,7 @@
<para>Alas, this scenario doesn't work so well right now and
is considered one of Subversion's current weak spots. The
- problem is that Subversion's <command>update</command>
+ problem is that Subversion's <command>svn update</command>
command isn't as robust as it should be, particularly when
dealing with copy and move operations.</para>
@@ -2065,7 +2065,7 @@
<listitem>
<para>Don't ever edit the <literal>svn:mergeinfo</literal>
property directly; use <command>svn
- merge --record-only</command> to effect a desired change
+ merge</command> with the <option>--record-only</option> option to effect a desired change
to the metadata (as demonstrated in
<xref linkend="svn.branchmerge.advanced.blockchanges"/>).</para>
</listitem>
@@ -2335,8 +2335,8 @@
of your work, you may decide that you need to create a working
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), by switching files and directories to
+ directories to particular revisions (using <command>svn update</command>
+ with the <option>-r</option> option liberally), by switching files and directories to
particular branches (making use of <command>svn
switch</command>), or even just by making a bunch of local
changes. When you're done, your working copy is a hodgepodge
Modified: trunk/src/en/book/ch08-embedding-svn.xml
==============================================================================
--- trunk/src/en/book/ch08-embedding-svn.xml (original)
+++ trunk/src/en/book/ch08-embedding-svn.xml Fri Jul 25 00:16:27 2008
@@ -430,7 +430,7 @@
to use for the task at hand. You can determine which RA
modules are available to the Subversion command-line client,
and what protocols they claim to support, by running
- <command>svn --version</command>:</para>
+ <userinput>svn --version</userinput>:</para>
<screen>
$ svn --version
More information about the svnbook-dev
mailing list