[svnbook] r5444 committed - branches/1.8/zh
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Tue Oct 3 04:17:38 CDT 2017
Revision: 5444
http://sourceforge.net/p/svnbook/source/5444
Author: wuzhouhui
Date: 2017-10-03 09:17:37 +0000 (Tue, 03 Oct 2017)
Log Message:
-----------
1.8/zh: Merge English trunk
Modified Paths:
--------------
branches/1.8/zh/book/ch00-preface.xml
branches/1.8/zh/book/ch03-advanced-topics.xml
branches/1.8/zh/book/ch04-branching-and-merging.xml
branches/1.8/zh/book/ch05-repository-admin.xml
branches/1.8/zh/book/ch06-server-configuration.xml
branches/1.8/zh/book/ref-svn.xml
Property Changed:
----------------
branches/1.8/zh/
Index: branches/1.8/zh
===================================================================
--- branches/1.8/zh 2017-10-02 14:55:31 UTC (rev 5443)
+++ branches/1.8/zh 2017-10-03 09:17:37 UTC (rev 5444)
Property changes on: branches/1.8/zh
___________________________________________________________________
Added: svn:mergeinfo
## -0,0 +1 ##
+/trunk/en:5303-5443
\ No newline at end of property
Modified: branches/1.8/zh/book/ch00-preface.xml
===================================================================
--- branches/1.8/zh/book/ch00-preface.xml 2017-10-02 14:55:31 UTC (rev 5443)
+++ branches/1.8/zh/book/ch00-preface.xml 2017-10-03 09:17:37 UTC (rev 5444)
@@ -305,7 +305,7 @@
version control</firstterm> has likewise garnered widespread
attention and adoption. Tools such as Git
(<ulink url="http://git-scm.com/" />) and Mercurial
- (<ulink url="http://mercurial.selenic.com/" />) have risen
+ (<ulink url="http://mercurial-scm.org/" />) have risen
to the tops of the distributed version control system (DVCS)
ranks. Distributed version control harnesses the growing
ubiquity of high-speed network connections and low storage
@@ -345,7 +345,7 @@
more complicated model, which can present a non-negligible
challenge to comfortable collaboration. Also, DVCS tools do
what they do well in part because of a certain degree of
- control withheld from the user which centalized systems freely
+ control withheld from the user which centralized systems freely
offer—the ability to implement path-based access
control, the flexibility to update or backdate individual
versioned data items, etc. Fortunately, many wise
@@ -1034,7 +1034,7 @@
the use of backward slashes (<literal>\</literal>) instead of
forward slashes (<literal>/</literal>) for path separators, the
input to and output from this tool when run on Windows are
- identical to that of its Unix counterpart.</para>
+ identical to those of its Unix counterpart.</para>
-->
<para>为方便讨论, 本书的例子假设读者使用的是类 Unix 操作系统, 并且熟悉
Unix 和命令行界面, 当然, <command>svn</command> 也可以在非 Unix 平台上
Modified: branches/1.8/zh/book/ch03-advanced-topics.xml
===================================================================
--- branches/1.8/zh/book/ch03-advanced-topics.xml 2017-10-02 14:55:31 UTC (rev 5443)
+++ branches/1.8/zh/book/ch03-advanced-topics.xml 2017-10-03 09:17:37 UTC (rev 5444)
@@ -439,18 +439,24 @@
<warning>
<!--
- <para>Since the timestamp of a revision is stored as an
- unversioned, modifiable property of the revision (see <xref
- linkend="svn.advanced.props" />), revision timestamps can be
- changed to represent complete falsifications of true
- chronology, or even removed altogether. Subversion's
- ability to correctly convert revision dates into real
- revision numbers depends on revision datestamps maintaining
- a sequential ordering—the younger the revision, the
- younger its timestamp. If this ordering isn't maintained,
- you will likely find that trying to use dates to specify
- revision ranges in your repository doesn't always return the
- data you might have expected.</para>
+ <para>Subversion's ability to correctly convert revision dates
+ into real revision numbers depends on revision datestamps
+ maintaining a sequential ordering—the younger the
+ revision, the younger its datestamp. But datestamps are
+ stored in the unversioned, modifiable
+ <literal>svn:date</literal> property of the revision (see
+ <xref linkend="svn.advanced.props" />), so it is possible
+ for revision datestamps to get out of sequence. Now, most
+ of Subversion's operations are unaffected by this
+ situation—after all, the revision number itself is the
+ primary identifier of each revision. But if the datestamp
+ ordering isn't maintained, you will likely find that trying
+ to use dates to specify revision ranges in your repository
+ doesn't always return the data you might have expected.
+ Combining the histories of multiple repositories into a
+ single one (as described in
+ <xref linkend="svn.reposadmin.maint.migrate" />) is the most
+ common cause of this scenario.</para>
-->
<para>因为版本号的时间戳被当成属性存放在版本号中, 而该属性是可修改的
且未被纳入版本管理 (见 <xref linkend="svn.advanced.props"/>), 因此
@@ -2061,7 +2067,7 @@
<!--
<para>If we were to instead make the target of the subcommand the
subdirectory <filename>site</filename>, then using the <option>
- -show-inherited-props</option> option, we find that the <literal>
+ --show-inherited-props</option> option, we find that the <literal>
svn:auto-props</literal> property is set on the target <emphasis>
and</emphasis> its parent. The parent's properties are called out
as "inherited":</para>
@@ -5995,7 +6001,7 @@
<sidebar id="svn.advanced.locking.meanings">
<!--
- <title>The Three Meanings of <quote>Lock</quote></title>
+ <title>The Many Meanings of <quote>Lock</quote></title>
-->
<title><quote>锁</quote> 的 3 种涵义</title>
@@ -6003,7 +6009,7 @@
<para>In this section, and almost everywhere in this book, the
words <quote>lock</quote> and <quote>locking</quote> describe
a mechanism for mutual exclusion between users to avoid
- clashing commits. Unfortunately, there are two other sorts
+ clashing commits. Unfortunately, there are other sorts
of <quote>lock</quote> with which Subversion, and therefore
this book, sometimes needs to be concerned.</para>
-->
@@ -6024,8 +6030,8 @@
<command>svn cleanup</command> 会删除管理锁, 见
<xref linkend="svn.tour.cleanup"/>.</para>
<!--
- The second is <firstterm>administrative
- locks</firstterm>, used internally by Subversion to prevent
+ </indexterm>Subversion uses <firstterm>administrative
+ locks</firstterm> internally to prevent
clashes between multiple Subversion clients operating on the
same working copy. This is the sort of lock indicated by an
<computeroutput>L</computeroutput> in the third column of
@@ -6043,17 +6049,38 @@
</firstterm>), 由 Berkeley DB 内部使用, 防止多个程序在访问数据库时
产生碰撞.</para>
<!--
- Third, there are <firstterm>database
- locks</firstterm>, used internally by the Berkeley DB backend
- to prevent clashes between multiple programs trying to access
- TODO
- the database. This is the sort of lock whose unwanted
- persistence after an error can cause a repository to
- be <quote>wedged,</quote> as described in
+ </indexterm>Administrators using the older Berkeley DB repository
+ backend will need to be familiar with <firstterm>database
+ locks</firstterm>, which exist to prevent clashes between multiple
+ programs trying to access the database. This is the sort of lock
+ whose unwanted persistence after an error can cause a repository
+ to be <quote>wedged,</quote> as described in
<xref linkend="svn.berkeleydb.maintenance.recovery" />.</para>
-->
<!--
+ <para>
+ <indexterm>
+ <primary>locks</primary>
+ <secondary>svnsync</secondary>
+ </indexterm>Additionally, there are <firstterm>svnsync
+ locks</firstterm>, which effect mutual exclusion between multiple
+ instances of the <command>svnsync</command> command that write
+ to the same mirror of a repository. This is the sort of lock
+ implemented by the <literal>svn:sync-lock</literal> revision
+ property, as described in <xref
+ linkend="svn.reposadmin.maint.replication.svnsync" />.</para>
+
+ <para>
+ <indexterm>
+ <primary>locks</primary>
+ <secondary>svnrdump</secondary>
+ </indexterm>Finally, there are <firstterm>svnrdump
+ locks</firstterm>. These are very much like svnsync locks, but
+ are associated with the <command>svnrdump</command> command
+ (described in <xref linkend="svn.reposadmin.maint.migrate.svnrdump"
+ />) instead of <command>svnsync</command>.</para>
+
<para>You can generally forget about these other kinds of locks
until something goes wrong that requires you to care about
them. In this book, <quote>lock</quote> means the first sort
Modified: branches/1.8/zh/book/ch04-branching-and-merging.xml
===================================================================
--- branches/1.8/zh/book/ch04-branching-and-merging.xml 2017-10-02 14:55:31 UTC (rev 5443)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml 2017-10-03 09:17:37 UTC (rev 5444)
@@ -980,35 +980,38 @@
test, and <command>svn commit</command> the local modifications
to your branch.</para>
- <sidebar id="svn.branchmerge.basicmerging.stayinsync.subtree">
- <title>Subtree Merges and Subtree Mergeinfo</title>
- <para>
- <indexterm>
- <primary>merging</primary>
- <secondary>subtree merge</secondary>
- </indexterm>
- <indexterm>
- <primary>mergeinfo</primary>
- <secondary>subtree mergeinfo</secondary>
- </indexterm>In most of the examples in this chapter the
- merge target is the root directory of a branch (see
- <xref linkend="svn.branchmerge.whatis"/>). While this is a
- best practice, you may occasionally need to merge directly
- to some child of the branch root. This type of merge is
- called a <firstterm>subtree merge</firstterm> and the
- mergeinfo recorded to describe it is called
- <firstterm>subtree mergeinfo</firstterm>. There is nothing
- special about subtree merges or subtree mergeinfo. In fact
- there is really only one important point to keep in mind
- about these concepts: the complete record of merges to a
- branch may not be contained solely in the mergeinfo on the
- branch root. You may have to consider subtree mergeinfo
- to get a full accounting. Fortunately Subversion does this
- for you and rarely will you need to concern yourself with
- it. A brief example will help explain:</para>
+ </sect2>
- <informalexample>
- <screen>
+ <!-- =============================================================== -->
+ <sect2 id="svn.branchmerge.basicmerging.stayinsync.subtree">
+ <title>Subtree Merges and Subtree Mergeinfo</title>
+ <para>
+ <indexterm>
+ <primary>merging</primary>
+ <secondary>subtree merge</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>mergeinfo</primary>
+ <secondary>subtree mergeinfo</secondary>
+ </indexterm>In most of the examples in this chapter the
+ merge target is the root directory of a branch (see
+ <xref linkend="svn.branchmerge.whatis"/>). While this is a
+ best practice, you may occasionally need to merge directly
+ to some child of the branch root. This type of merge is
+ called a <firstterm>subtree merge</firstterm> and the
+ mergeinfo recorded to describe it is called
+ <firstterm>subtree mergeinfo</firstterm>. There is nothing
+ special about subtree merges or subtree mergeinfo. In fact
+ there is really only one important point to keep in mind
+ about these concepts: the complete record of merges to a
+ branch may not be contained solely in the mergeinfo on the
+ branch root. You may have to consider subtree mergeinfo
+ to get a full accounting. Fortunately Subversion does this
+ for you and rarely will you need to concern yourself with
+ it. A brief example will help explain:</para>
+
+ <informalexample>
+ <screen>
# We need to merge r958 from trunk to branches/proj-X/doc/INSTALL,
# but that revision also affects main.c, which we don't want to merge:
$ svn log --verbose --quiet -r 958 ^/
@@ -1058,26 +1061,24 @@
--- Eliding mergeinfo from 'doc/INSTALL':
U doc/INSTALL
</screen>
- </informalexample>
+ </informalexample>
- <para>
- <indexterm>
- <primary>mergeinfo</primary>
- <secondary>elision</secondary>
- </indexterm>You might be wondering
- why <filename>INSTALL</filename> in the above example has
- mergeinfo for r651-652, when we only merged r958. This is
- due to mergeinfo inheritance, which we'll cover in the
- sidebar
- <xref linkend="svn.branchmerge.basicmerging.mergeinfo.inheritance"
- />. Also note that the subtree mergeinfo on
- <filename>doc/INSTALL</filename> was removed, or
- <quote>elided</quote>. This is called
- <firstterm>mergeinfo elision</firstterm> and it occurs
- whenever Subversion detects redundant subtree mergeinfo.</para>
+ <para>
+ <indexterm>
+ <primary>mergeinfo</primary>
+ <secondary>elision</secondary>
+ </indexterm>You might be wondering
+ why <filename>INSTALL</filename> in the above example has
+ mergeinfo for r651-652, when we only merged r958. This is
+ due to mergeinfo inheritance, which we'll cover in the
+ sidebar
+ <xref linkend="svn.branchmerge.basicmerging.mergeinfo.inheritance"
+ />. Also note that the subtree mergeinfo on
+ <filename>doc/INSTALL</filename> was removed, or
+ <quote>elided</quote>. This is called
+ <firstterm>mergeinfo elision</firstterm> and it occurs
+ whenever Subversion detects redundant subtree mergeinfo.</para>
- </sidebar>
-
<tip>
<para>Prior to Subversion 1.7, merges unconditionally updated
<emphasis>all</emphasis> of the subtree mergeinfo under the
@@ -1284,7 +1285,11 @@
<sect2 id="svn.branchmerge.basicmerging.mergeinfo">
<title>Mergeinfo and Previews</title>
- <para>The basic mechanism Subversion uses to track
+ <para>
+ <indexterm>
+ <primary>mergeinfo</primary>
+ <secondary>property</secondary>
+ </indexterm>The basic mechanism Subversion uses to track
changesets—that is, which changes have been merged to
which branches—is by recording data in versioned
properties. Specifically, merge data is tracked in
@@ -3235,7 +3240,6 @@
<xref linkend="svn.reposadmin.hooks" />.</para>
</sect2>
-
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.advanced.finalword">
<title>The Final Word on Merge Tracking</title>
Modified: branches/1.8/zh/book/ch05-repository-admin.xml
===================================================================
--- branches/1.8/zh/book/ch05-repository-admin.xml 2017-10-02 14:55:31 UTC (rev 5443)
+++ branches/1.8/zh/book/ch05-repository-admin.xml 2017-10-03 09:17:37 UTC (rev 5444)
@@ -962,23 +962,24 @@
APIs.</para>
<warning>
- <para>While hook scripts can do almost anything, there is
- one dimension in which hook script authors should show
- restraint: do <emphasis>not</emphasis> modify a commit
- transaction using hook scripts. While it might be
- tempting to use hook scripts to automatically correct
- errors, shortcomings, or policy violations present in the
- files being committed, doing so can cause problems.
- Subversion keeps client-side caches of certain bits of
- repository data, and if you change a commit transaction in
- this way, those caches become indetectably stale. This
- inconsistency can lead to surprising and unexpected
- behavior. Instead of modifying the transaction, you
- should simply <emphasis>validate</emphasis> the
- transaction in the <filename>pre-commit</filename> hook
- and reject the commit if it does not meet the desired
- requirements. As a bonus, your users will learn the value
- of careful, compliance-minded work habits.</para>
+ <para>Hook scripts can do almost anything, but hook script
+ authors should show restraint. It might be tempting to,
+ say, use hook scripts to automatically correct errors,
+ shortcomings, or policy violations present in the files
+ being committed. Unfortunately, doing so can cause
+ problems. Subversion keeps client-side caches of certain
+ bits of repository data, and if you change a commit
+ transaction in this way, those caches become indetectably
+ stale, leading to surprising and unexpected behavior.
+ While it is generally okay to add new commit transaction
+ properties via a hook script, essentially everything else
+ about a commit transaction should be considered read-only.
+ Instead of modifying a transaction to polish its payload,
+ simply <emphasis>validate</emphasis> the transaction in
+ the <filename>pre-commit</filename> hook and reject the
+ commit if it does not meet the desired requirements. As a
+ bonus, your users will learn the value of careful,
+ compliance-minded work habits.</para>
</warning>
</sect3>
Modified: branches/1.8/zh/book/ch06-server-configuration.xml
===================================================================
--- branches/1.8/zh/book/ch06-server-configuration.xml 2017-10-02 14:55:31 UTC (rev 5443)
+++ branches/1.8/zh/book/ch06-server-configuration.xml 2017-10-03 09:17:37 UTC (rev 5444)
@@ -1503,7 +1503,7 @@
<informalexample>
<programlisting>
[tunnels]
-rsh = rsh
+rsh = rsh --
</programlisting>
</informalexample>
@@ -1511,17 +1511,28 @@
URL scheme that matches the name of your new variable:
<literal>svn+rsh://host/path</literal>. When using the new
URL scheme, the Subversion client will actually be running the
- command <userinput>rsh host svnserve -t</userinput> behind the
+ command <userinput>rsh -- host svnserve -t</userinput> behind the
scenes. If you include a username in the URL (e.g.,
<literal>svn+rsh://username@host/path</literal>), the client
- will also include that in its command (<userinput>rsh
- username at host svnserve -t</userinput>). But you can define new
- tunneling schemes to be much more clever than that:</para>
+ will also include that in its command (<userinput>rsh --
+ username at host svnserve -t</userinput>).</para>
+ <warning>
+ <para>Notice that when defining an RSH-based tunnel, we've
+ added the <literal>--</literal> end-of-options argument to
+ the tunnel command line. This is to prevent a malformed
+ hostname from being treated as another option to the tunnel
+ command. You should do the same for other tunnel programs
+ (for example, SSH).</para>
+ </warning>
+
+ <para>But you can define new tunneling schemes to be much more
+ clever than that:</para>
+
<informalexample>
<programlisting>
[tunnels]
-joessh = $JOESSH /opt/alternate/ssh -p 29934
+joessh = $JOESSH /opt/alternate/ssh -p 29934 --
</programlisting>
</informalexample>
Modified: branches/1.8/zh/book/ref-svn.xml
===================================================================
--- branches/1.8/zh/book/ref-svn.xml 2017-10-02 14:55:31 UTC (rev 5443)
+++ branches/1.8/zh/book/ref-svn.xml 2017-10-03 09:17:37 UTC (rev 5444)
@@ -70,7 +70,10 @@
--username ARG : specify a username ARG
--password ARG : specify a password ARG
--no-auth-cache : do not cache authentication tokens
- --non-interactive : do no interactive prompting
+ --non-interactive : do no interactive prompting (default is to prompt
+ only if standard input is a terminal device)
+ --force-interactive : do interactive prompting even if standard input
+ is not a terminal device
--trust-server-cert : accept SSL server certificates from unknown
certificate authorities without prompting (but only
with '--non-interactive')
@@ -470,6 +473,19 @@
</listitem>
</varlistentry>
+ <varlistentry id="svn.ref.svn.sw.force_interactive">
+ <term><option>--force-interactive</option></term>
+ <listitem>
+ <para>Forces the <command>svn</command> command-line client to run in
+ interactive mode when standard input is not a terminal device.</para>
+
+ <note>
+ <para>This option is accepted by
+ all <command>svn</command> subcommands.</para>
+ </note>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="svn.ref.svn.sw.git">
<term><option>--git</option></term>
<listitem>
@@ -688,6 +704,12 @@
have Subversion fail than to prompt for more
information.</para>
+ <para>Beginning with Subversion 1.8, the <command>svn</command>
+ command-line client, by default, is non-interactive when standard
+ input is not a terminal device. Pass the
+ <option>--force-interactive</option> option to make the client run
+ in interactive mode.</para>
+
<note>
<para>This option is accepted by
all <command>svn</command> subcommands.</para>
More information about the svnbook-dev
mailing list