[svnbook commit] r2594 - branches/ora-2e-reorg/src/en/book
cmpilato
noreply at red-bean.com
Wed Jan 3 12:24:55 CST 2007
Author: cmpilato
Date: Wed Jan 3 12:24:55 2007
New Revision: 2594
Modified:
branches/ora-2e-reorg/src/en/book/ch-advanced-topics.xml
Log:
* src/en/book/ch-advanced-topics.xml
(Peg and Operative Revisions): Finish ticket #13, adding a notation
about the at-syntax escaping mechanism.
Modified: branches/ora-2e-reorg/src/en/book/ch-advanced-topics.xml
==============================================================================
--- branches/ora-2e-reorg/src/en/book/ch-advanced-topics.xml (original)
+++ branches/ora-2e-reorg/src/en/book/ch-advanced-topics.xml Wed Jan 3 12:24:55 2007
@@ -244,6 +244,23 @@
working copy paths, and of <literal>HEAD</literal> when applied
to URLs.</para>
+ <para>The perceptive reader is probably wondering at this point if
+ the peg revision syntax causes problems for working copy paths
+ or URLs that actually have ampersand characters in them. After
+ all, how does <command>svn</command> know whether
+ <literal>news at 11</literal> is the name of a directory in my
+ tree, or just a syntax for <quote>revision 11 of
+ <filename>news</filename></quote>? Thankfully, while
+ <command>svn</command> will always assume the latter, there is a
+ trivial workaround. You need only append an ampersand to the
+ end of the path, such as <literal>news at 11@</literal>.
+ <command>svn</command> only cares about the last ampersand in
+ the argument, and it is not considered illegal to omit a literal
+ peg revision specifier after that ampersand. This workaround
+ even applies to paths that end in an ampersand—you would
+ use <literal>filename@@</literal> to talk about a file named
+ <filename>filename@</filename>.</para>
+
<para>Let's ask the other question, then—in revision 1, what
were the contents of whatever file occupied the address
<filename>concepts/IDEA</filename> at the time? We'll use an
More information about the svnbook-dev
mailing list