[svnbook commit] r2811 - in trunk/src/ru: . book

dmitriy noreply at red-bean.com
Thu Jun 28 20:00:33 CDT 2007


Author: dmitriy
Date: Thu Jun 28 20:00:32 2007
New Revision: 2811

Log:
* ru/book/ch-advanced-topics.xml: merge r2607

* ru/book/ch-fundamental-concepts.xml: merge r2608

* ru/sync.py: pre-save working copes of *.xml before sync

Modified:
   trunk/src/ru/book/   (props changed)
   trunk/src/ru/book/ch-advanced-topics.xml
   trunk/src/ru/book/ch-fundamental-concepts.xml
   trunk/src/ru/sync.py

Modified: trunk/src/ru/book/ch-advanced-topics.xml
==============================================================================
--- trunk/src/ru/book/ch-advanced-topics.xml	(original)
+++ trunk/src/ru/book/ch-advanced-topics.xml	Thu Jun 28 20:00:32 2007
@@ -34,15 +34,13 @@
   <!-- @ENGLISH {{{
   <para>But the Subversion feature set doesn't stop at <quote>common
     version control operations</quote>.  It has other bits of
-    functionality that extend beyond basic file and directory
-    versioning; beyond just sending and receiving changes to and from
-    a central repository.</para>
+    functionality that extend beyond just communicating file and
+    directory changes to and from a central repository.</para>
   @ENGLISH }}} -->
   <para>Однако предоставляемый Subversion набор возможностей не
     ограничивается <quote>типовыми операциями управления
     версиями</quote>.  У Subversion есть функциональнось, выходящая за пределы
-    обычного версионирования файлов и директорий; идущая дальше простой
-    отправки и получения различий в и из центрального хранилища.
+    простого обмена различиями с центральным хранилищем.
   </para>
 
   <!-- @ENGLISH {{{
@@ -69,7 +67,7 @@
   <sect1 id="svn.tour.revs.specifiers">
     <title>Revision Specifiers</title>
 
-    <para>As we saw in <xref linkend="svn.tour.revs" />, revision
+    <para>As you saw in <xref linkend="svn.tour.revs" />, revision
       numbers in Subversion are pretty straightforward—integers
       that keep getting larger as you commit more changes to your
       versioned data.  Still, it doesn't take long before you can no
@@ -180,13 +178,11 @@
         types.</para>
       
       <!-- @ENGLISH {{{
-      <para>Here are some examples of revision keywords in action.
-        Don't worry if the commands don't make sense yet; we'll be
-        explaining these commands as we go through the chapter:</para>
+      <para>Here are some examples of revision keywords in
+        action:</para>
       @ENGLISH }}} -->
       <para>Ниже приведено несколько примеров использования ключевых слов
-        правок. Не волнуйтесь, если смысл команд пока не понятен; в дальнейшем
-        мы объясним эти команды:</para>
+        правок:</para>
 
       <screen>
 $ svn diff --revision PREV:COMMITTED foo.c
@@ -368,10 +364,10 @@
       flexibility for versioned files as you'd expect when
       manipulating your unversioned ones.  But that flexibility means
       that across the lifetime of your repository, a given versioned
-      resource might have many paths, and a given path might represent
-      several entirely different versioned resources.  And this
+      object might have many paths, and a given path might represent
+      several entirely different versioned objects.  And this
       introduces a certain level of complexity to your interactions
-      with those paths and resources.</para>
+      with those paths and objects.</para>
 
     <para>Subversion is pretty smart about noticing when an object's
       version history includes such <quote>changes of address</quote>.
@@ -397,7 +393,7 @@
       ever lived at that path?  Clearly, Subversion needs a hint about
       what you really want.</para>
 
-    <para>And thanks to moves, versioned resource history can get far
+    <para>And thanks to moves, versioned object history can get far
       more twisted than that, even.  For example, you might have a
       directory named <filename>concept</filename>, containing some
       nascent software project you've been toying with.  Eventually,
@@ -443,7 +439,7 @@
       it exactly which Main Street you meant.  It's called the
       <firstterm>peg revision</firstterm>, and it is a revision
       provided to Subversion for the sole purpose of identifying a
-      unique line of history.  Because at most one versioned resource
+      unique line of history.  Because at most one versioned object
       may occupy a path at any given time—or, more precisely, in
       any one revision—the combination of a path and a peg
       revision is all that is needed to refer to a specific line of
@@ -477,13 +473,13 @@
       go.</para>
 
     <sidebar>
-      <title>The "peg-revision" algorithm</title>
+      <title>The peg revision algorithm</title>
       
-      <para>The Subversion command-line performs the peg-revision
-        algorithm basically any time it needs to resolve possible
-        ambiguities in the paths and revisions provided to it.  Here's
-        an example of such an invocation for the purposes of
-        illustrating that algorithm.</para>
+      <para>The Subversion command-line performs the peg revision
+        algorithm any time it needs to resolve possible ambiguities in
+        the paths and revisions provided to it.  Here's an example of
+        such an invocation for the purposes of illustrating that
+        algorithm.</para>
 
       <screen>
 $ svn <replaceable>command</replaceable> -r <replaceable>OPERATIVE-REV</replaceable> item@<replaceable>PEG-REV</replaceable>
@@ -1249,7 +1245,9 @@
           value of the property they are about to change, which helps
           them to verify that they are, in fact, making the change
           they think they are making.  This is especially true when
-          modifying unversioned revision properties.</para>
+          modifying unversioned revision properties.  Also, it is
+          significantly easier to modify multiline property values in
+          a text editor than at the command line.</para>
       </tip>
 
     </sect2>
@@ -1335,8 +1333,8 @@
         <para>As with file contents, local property modifications can
           conflict with changes committed by someone else.  If you
           update your working copy directory and receive property
-          changes on a versioned resource that clash with your own,
-          Subversion will report that the resource is in a conflicted
+          changes on a versioned object that clash with your own,
+          Subversion will report that the object is in a conflicted
           state.</para>
         @ENGLISH }}} -->
         <title>Конфликты свойств</title>
@@ -1345,8 +1343,8 @@
           модификации свойств могут конфликтовать с изменениями,
           зафиксированными кем-то другим. При обновлении рабочей копии
           директории и получении изменений свойств для версионированного
-          элемента, которые идут в разрез вашими собственными, Subversion
-          сообщит о конфликтном состоянии элемента.</para>
+          объекта, которые идут в разрез вашими собственными, Subversion
+          сообщит о конфликтном состоянии объекта.</para>
 
         <screen>
 % svn update calc
@@ -1358,16 +1356,16 @@
 
         <!-- @ENGLISH {{{
         <para>Subversion will also create, in the same directory as
-          the conflicted resource, a file with a
+          the conflicted object, a file with a
           <filename>.prej</filename> extension which contains the
           details of the conflict.  You should examine the contents of
           this file so you can decide how to resolve the conflict.
           Until the conflict is resolved, you will see a
           <literal>C</literal> in the second column of <command>svn
-          status</command> output for that resource, and attempts to
+          status</command> output for that object, and attempts to
           commit your local modifications will fail.</para>
         @ENGLISH }}} -->
-        <para>В директории с конфликтующим элементом Subversion
+        <para>В директории с конфликтующим обектом Subversion
           создает файл с расширением <filename>.prej</filename>,
           с подробностями о конфликте. Для разрешения конфликта
           необходимо познакомиться с содержимым этого файла. Пока
@@ -1481,24 +1479,26 @@
         linkend="svn.advanced.props.special.mime-type" />.)</para>
 
       <para>Subversion also provides, via its runtime configuration
-        system, a more flexible automatic property setting feature
-        which allows you to create mappings of filename patterns to
-        property names and values.  Once again, these mappings affect
-        adds and imports, and not only can override the default MIME
-        type decision made by Subversion during those operations, but
-        can also set additional Subversion or custom properties, too.
-        For example, you might create a mapping that says that any
-        time you add JPEG files—ones that match the pattern
+        system (see <xref linkend="svn.advanced.confarea" />), a more
+        flexible automatic property setting feature which allows you
+        to create mappings of filename patterns to property names and
+        values.  Once again, these mappings affect adds and imports,
+        and not only can override the default MIME type decision made
+        by Subversion during those operations, but can also set
+        additional Subversion or custom properties, too.  For example,
+        you might create a mapping that says that any time you add
+        JPEG files—ones that match the pattern
         <literal>*.jpg</literal>—Subversion should automatically
         set the <literal>svn:mime-type</literal> property on those
         files to <literal>image/jpeg</literal>.  Or perhaps any files
         that match <literal>*.cpp</literal> should have
         <literal>svn:eol-style</literal> set to
         <literal>native</literal>, and <literal>svn:keywords</literal>
-        set to <literal>Id</literal>.  Auto-prop support is perhaps
-        the handiest property related tool in the Subversion toolbox.
-        See <xref linkend="svn.advanced.confarea.opts.config"/> for
-        more about configuring that support.</para>
+        set to <literal>Id</literal>.  Automatic property support is
+        perhaps the handiest property related tool in the Subversion
+        toolbox.  See <xref
+        linkend="svn.advanced.confarea.opts.config"/> for more about
+        configuring that support.</para>
 
     </sect2>     
   </sect1>
@@ -1511,10 +1511,10 @@
 
     <para>Fortunately for Subversion users who routinely find
       themselves on different computers with different operating
-      systems, Subversion's command-line programs almost universally
-      behave identically across all those systems.  If you know how to
-      wield <command>svn</command> on one platform, you know how to
-      wield it everywhere.</para>
+      systems, Subversion's command-line program behaves almost
+      identically on all those systems.  If you know how to wield
+      <command>svn</command> on one platform, you know how to wield it
+      everywhere.</para>
 
     <para>However, the same is not always true of other general classes
       of software, or of the actual files you keep in Subversion.  For
@@ -1824,13 +1824,13 @@
 
     <para>In any given working copy there is a good chance that
       alongside all those versioned files and directories are other
-      files and directories which are not, and are not intended to be,
-      themselved versioned.  Text editors litter directories with
-      backup files.  Code compilation processes generate
-      intermediate—or even final—files which you typically
-      wouldn't bother to version.  And users themselves drop various
-      other files and directories wherever they see fit, often in
-      version control working copies.</para>
+      files and directories which are neither versioned nor intended
+      to be.  Text editors litter directories with backup files.  Code
+      compilation processes generate intermediate—or even
+      final—files which you typically wouldn't bother to
+      version.  And users themselves drop various other files and
+      directories wherever they see fit, often in version control
+      working copies.</para>
 
     <para>It's ludicrous to expect Subversion working copies to be
       somehow impervious to this kind of clutter and impurity.  In
@@ -1851,13 +1851,14 @@
     <para>So Subversion provides a pair of ways for telling it which
       files you would prefer that it simply disregard.  One of the
       ways involves the use of Subversion's runtime configuration
-      system, and therefore applies to all the Subversion operations
-      which make use of that runtime configuration, generally those
-      performed on a particular computer, or by a particular user of a
-      computer.  The other way makes use of Subversion's directory
-      property support, is more tightly bound to the versioned tree
-      itself, and therefore affects everyone who has a working copy of
-      that tree.  Both of the mechanisms use file patterns.</para>
+      system (see <xref linkend="svn.advanced.confarea" />), and
+      therefore applies to all the Subversion operations which make
+      use of that runtime configuration, generally those performed on
+      a particular computer, or by a particular user of a computer.
+      The other way makes use of Subversion's directory property
+      support, is more tightly bound to the versioned tree itself, and
+      therefore affects everyone who has a working copy of that tree.
+      Both of the mechanisms use file patterns.</para>
 
     <para>The Subversion runtime configuration system provides an
       option, <literal>global-ignores</literal>, whose value is a
@@ -1900,7 +1901,7 @@
         to avoid committing changes you've made to a versioned file
         simply because that file's name matches an ignore
         pattern—Subversion <emphasis>always</emphasis> notices
-        all of its versioned resources.</para>
+        all of its versioned objects.</para>
     </warning>
 
     <sidebar>
@@ -2185,25 +2186,6 @@
       will not substitute keywords that are not present in the
       <literal>svn:keywords</literal> property value.</para>
 
-    <sidebar>
-      <title>Keywords and Spurious Differences</title>
-
-      <para>The user-visible result of keyword substitution might
-        lead you to think that every version of a file with that
-        feature in use differs from the previous version in at
-        least the area where the keyword anchor was placed.
-        However, this is actually not the case.  While checking
-        for local modifications during <command>svn
-        diff</command>, and before transmitting those local
-        modifications during <command>svn commit</command>,
-        Subversion <quote>un-substitutes</quote> any keywords that
-        it previously substituted.  The result is that the
-        versions of the file that are stored in the repository
-        contain only the real modifications that users make to the
-        file.</para>
-
-    </sidebar>
-
     <para>Immediately after you commit this property change,
       Subversion will update your working file with the new
       substitute text.  Instead of seeing your keyword anchor
@@ -2234,6 +2216,13 @@
       file will be re-substituted with information that
       reflects the most recent known commit to that file.</para>
 
+    <sidebar>
+      <title>Where's $GlobalRev$?</title>
+
+      <para>### TODO:  Write me</para>
+
+    </sidebar>
+
     <para>Subversion 1.2 introduced a new variant of the keyword
       syntax which brought additional, useful—though perhaps
       atypical—functionality.  You can now tell Subversion
@@ -2338,17 +2327,17 @@
     <title>Locking</title>
 
     <para>Subversion's copy-modify-merge version control model lives
-      and dies by the granularity of the data merging algorithms
-      employed when trying to resolve conflicts caused by multiple
-      users modifying the same file concurrently.  Subversion itself
-      provides only one such algorithm, a three-way differencing
-      algorithm which is smart enough to handle data at a granularity
-      of a single line of text.  Subversion also allows you to
-      supplement its content merge processing with external
+      and dies on its data merging algorithms, specifically on how
+      well those algorithms perform when trying to resolve conflicts
+      caused by multiple users modifying the same file concurrently.
+      Subversion itself provides only one such algorithm, a three-way
+      differencing algorithm which is smart enough to handle data at a
+      granularity of a single line of text.  Subversion also allows
+      you to supplement its content merge processing with external
       differencing utilities (as described in <xref
-      linkend="svn.advanced.externaldifftools.diff3" />), some of which
-      may do an even better job, perhaps providing granularity of a
-      word or a single character of text.  But common among those
+      linkend="svn.advanced.externaldifftools.diff3" />), some of
+      which may do an even better job, perhaps providing granularity
+      of a word or a single character of text.  But common among those
       algorithms is that they generally work only on text files.  The
       landscape starts to look pretty grim when you start talking
       about content merges of non-textual file formats.  And when you
@@ -2417,8 +2406,9 @@
       thing.  And this where Subversion's implementation of the
       lock-modify-unlock model steps into the spotlight.  This is
       where we talk about Subversion's <firstterm>locking</firstterm>
-      feature, which is similar to the reserved checkouts mechanisms
-      of other version control systems.</para>
+      feature, which is similar to the <quote>reserved
+      checkouts</quote> mechanisms of other version control
+      systems.</para>
 
     <para>Subversion's locking feature serves two main
       purposes:</para>
@@ -2426,18 +2416,17 @@
     <itemizedlist>
       <listitem>
         <para><emphasis>Serializing access to a versioned
-          resource</emphasis>.  But allowing a user to
+          object</emphasis>.  By allowing a user to
           programmatically claim the exclusive right to change to a
           file in the repository, that user can be reasonably
           confident that energy invested on unmergeable changes won't
-          be wasted; that his commit of those changes will
-          succeed.</para>
+          be wasted—his commit of those changes will succeed.</para>
       </listitem>
       <listitem>
         <para><emphasis>Aiding communication</emphasis>.  By alerting
           other users that serialization is in effect for particular
-          versioned resource, those other users can reasonably expect
-          that the resource is about to be changed by someone else,
+          versioned object, those other users can reasonably expect
+          that the object is about to be changed by someone else,
           and they, too, can avoid wasting their time and energy on
           unmergeable changes that won't be committable due to eventual
           out-of-dateness.</para>
@@ -2520,9 +2509,9 @@
         the <command>svn lock</command> command.</para>
 
       <screen>
-[harry] $ svn lock banana.jpg --message "Editing file for tomorrow's release."
+$ svn lock banana.jpg --message "Editing file for tomorrow's release."
 'banana.jpg' locked by user 'harry'.
-[harry] $
+$
 </screen>
 
       <para>There are a number of new things demonstrated in the
@@ -2553,10 +2542,10 @@
         info</command> reporting subcommands.</para>
 
       <screen>
-[harry] $ svn status
+$ svn status
      K banana.jpg
 
-[harry] $ svn info banana.jpg
+$ svn info banana.jpg
 Path: banana.jpg
 Name: banana.jpg
 URL: http://svn.example.com/repos/project/banana.jpg
@@ -2576,7 +2565,7 @@
 Lock Comment (1 line):
 Editing file for tomorrow's release.
 
-[harry] $
+$
 </screen>
 
       <para>That the <command>svn info</command> command, which does
@@ -2620,15 +2609,15 @@
         Sally is unable to change or delete that file:</para>
 
       <screen>
-[sally] $ svn delete banana.jpg
+$ svn delete banana.jpg
 D         banana.jpg
-[sally] $ svn commit -m "Delete useless file."
+$ svn commit -m "Delete useless file."
 Deleting       banana.jpg
 svn: Commit failed (details follow):
 svn: DELETE of
 '/repos/project/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc35d/banana.jpg':
 423 Locked (http://svn.example.com)
-[sally] $
+$
 </screen>
 
       <para>But Harry, after touching up the banana's shade of yellow,
@@ -2637,14 +2626,14 @@
         copy holds the correct lock token:</para>
 
       <screen>
-[harry] $ svn status
+$ svn status
 M    K banana.jpg
-[harry] $ svn commit -m "Make banana more yellow"
+$ svn commit -m "Make banana more yellow"
 Sending        banana.jpg
 Transmitting file data .
 Committed revision 2201.
-[harry] $ svn status
-[harry] $
+$ svn status
+$
 </screen>
 
       <para>Notice that after the commit is finished, <command>svn
@@ -2679,7 +2668,7 @@
         simple <command>svn unlock</command> command:</para>
 
       <screen>
-[harry] $ svn unlock banana.c
+$ svn unlock banana.c
 'banana.c' unlocked.
 </screen>
 
@@ -2694,12 +2683,12 @@
         these is <command>svn status --show-updates</command>:</para>
 
       <screen>
-[sally] $ svn status --show-updates
+$ svn status --show-updates
 M              23   bar.c
 M    O         32   raisin.jpg
        *       72   foo.h
 Status against revision:     105
-[sally] $
+$
 </screen>
 
       <para>In this example, Sally can see not only that her copy of
@@ -2714,7 +2703,7 @@
         answers:</para>
 
       <screen>
-[sally] $ svn info http://svn.example.com/repos/project/raisin.jpg
+$ svn info http://svn.example.com/repos/project/raisin.jpg
 Path: raisin.jpg
 Name: raisin.jpg
 URL: http://svn.example.com/repos/project/raisin.jpg
@@ -2729,7 +2718,7 @@
 Lock Created: 2005-02-16 13:29:18 -0500 (Wed, 16 Feb 2005)
 Lock Comment (1 line):
 Need to make a quick tweak to this image.
-[sally] $
+$
 </screen>
 
       <para>Just as <command>svn info</command> can be used to examine
@@ -2775,7 +2764,7 @@
         <xref linkend="svn.reposadmin.maint.tk"/>.)</para>
 
       <screen>
-[admin] $ svnadmin lslocks /usr/local/svn/repos
+$ svnadmin lslocks /usr/local/svn/repos
 Path: /project2/images/banana.jpg
 UUID Token: opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923
 Owner: frank
@@ -2792,34 +2781,34 @@
 Comment (1 line):
 Need to make a quick tweak to this image.
 
-[admin] $ svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg
+$ svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg
 Removed lock on '/project/raisin.jpg'.
-[admin] $
+$
 </screen>
 
       <para>The more interesting option is allowing users to break
-        each other's locks over the network.  To do this, one simply
+        each other's locks over the network.  To do this, Sally simply
         needs to pass the <option>--force</option> to the unlock
         command:</para>
 
       <screen>
-[sally] $ svn status --show-updates
+$ svn status --show-updates
 M              23   bar.c
 M    O         32   raisin.jpg
        *       72   foo.h
 Status against revision:     105
-[sally] $ svn unlock raisin.jpg
+$ svn unlock raisin.jpg
 svn: 'raisin.jpg' is not locked in this working copy
-[sally] $ svn info raisin.jpg | grep URL
+$ svn info raisin.jpg | grep URL
 URL: http://svn.example.com/repos/project/raisin.jpg
-[sally] $ svn unlock http://svn.example.com/repos/project/raisin.jpg
+$ svn unlock http://svn.example.com/repos/project/raisin.jpg
 svn: Unlock request failed: 403 Forbidden (http://svn.example.com)
-[sally] $ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
+$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
 'raisin.jpg' unlocked.
-[sally] $
+$
 </screen>
 
-      <para>Sally's initial attempt to unlock failed because she
+      <para>Now, Sally's initial attempt to unlock failed because she
         ran <command>svn unlock</command> directly on her working copy
         of the file, and no lock token was present.  To remove the
         lock directly from the repository, she needs to pass a URL
@@ -2839,15 +2828,15 @@
         might lock the file between the two commands.  The simpler thing
         to is <firstterm>steal</firstterm> the lock, which involves
         breaking and re-locking the file all in one atomic step.  To
-        do this, pass the <option>--force</option> option
+        do this, Sally passes the <option>--force</option> option
         to <command>svn lock</command>:</para>
 
       <screen>
-[sally] $ svn lock raisin.jpg
+$ svn lock raisin.jpg
 svn: Lock request failed: 423 Locked (http://svn.example.com)
-[sally] $ svn lock --force raisin.jpg
+$ svn lock --force raisin.jpg
 'raisin.jpg' locked by user 'sally'.
-[sally] $
+$
 </screen>
 
       <para>In any case, whether the lock is broken or stolen, Harry
@@ -2861,14 +2850,14 @@
         repository:</para>
 
       <screen>
-[harry] $ svn status
+$ svn status
      K raisin.jpg
-[harry] $ svn status --show-updates
+$ svn status --show-updates
      B         32   raisin.jpg
-[harry] $ svn update
+$ svn update
   B  raisin.jpg
-[harry] $ svn status
-[harry] $
+$ svn status
+$
 </screen>
 
       <para>If the repository lock was broken, then <command>svn
@@ -2956,19 +2945,19 @@
         discovers the pre-existing lock:</para>
 
       <screen>
-[sally] $ /usr/local/bin/gimp raisin.jpg
+$ /usr/local/bin/gimp raisin.jpg
 gimp: error: file is read-only!
-[sally] $ ls -l raisin.jpg
+$ ls -l raisin.jpg
 -r--r--r--   1 sally   sally   215589 Jun  8 19:23 raisin.jpg
-[sally] $ svn lock raisin.jpg
+$ svn lock raisin.jpg
 svn: Lock request failed: 423 Locked (http://svn.example.com)
-[sally] $ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
+$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
 Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
 Lock Owner: harry
 Lock Created: 2005-06-08 07:29:18 -0500 (Thu, 08 June 2005)
 Lock Comment (1 line):
 Making some tweaks.  Locking for the next two hours.
-[sally] $
+$
 </screen>
 
       <tip>
@@ -3024,7 +3013,7 @@
       <firstterm>externals definitions</firstterm>.  An externals
       definition is a mapping of a local directory to the
       URL—and possibly a particular revision—of a
-      versioned resource.  In Subversion, you declare externals
+      versioned object.  In Subversion, you declare externals
       definitions in groups using the <literal>svn:externals</literal>
       property.  You can create or modify this property using
       <command>svn propset</command> or <command>svn
@@ -3085,31 +3074,38 @@
       others update their working copies and receive your changes to
       the externals definition.</para>
 
-    <para>The <command>svn status</command> command also recognizes
-      externals definitions, displaying a status code of
-      <literal>X</literal> for the disjoint subdirectories into which
-      externals are checked out, and then recursing into those
-      subdirectories to display the status of the external items
-      themselves.</para>
+    <tip>
+      <para>Because the <literal>svn:externals</literal> property has
+        a multiline value, we strongly recommend that you use
+        <command>svn propedit</command> instead of <command>svn
+        propset</command>.</para>
+    </tip>
 
     <tip>
       <para>You should strongly consider using explicit revision
         numbers in all of your externals definitions.  Doing so means
         that you get to decide when to pull down a different snapshot
         of external information, and exactly which snapshot to pull.
-        Besides the common sense aspect of not being surprised by
-        changes to third-party repositories that you might not have
-        any control over, using explicit revision numbers also means
-        that as you backdate your working copy to a previous
-        revision, your externals definitions will also revert to the
-        way they looked in that previous revision, which in turn means
-        that the external working copies will be updated to match they
-        way <emphasis>they</emphasis> looked back when your repository was
+        Besides avoiding the surprise of getting changes to
+        third-party repositories that you might not have any control
+        over, using explicit revision numbers also means that as you
+        backdate your working copy to a previous revision, your
+        externals definitions will also revert to the way they looked
+        in that previous revision, which in turn means that the
+        external working copies will be updated to match they way
+        <emphasis>they</emphasis> looked back when your repository was
         at that previous revision.  For software projects, this could
         be the difference between a successful and a failed build of
-        an older snapshot of your complex codebase.</para>
+        an older snapshot of your complex codebase.</para> 
     </tip>
 
+    <para>The <command>svn status</command> command also recognizes
+      externals definitions, displaying a status code of
+      <literal>X</literal> for the disjoint subdirectories into which
+      externals are checked out, and then recursing into those
+      subdirectories to display the status of the external items
+      themselves.</para>
+
     <para>The support that exists for externals definitions in
       Subversion today can be a little misleading, though.  First, an
       externals definition can only point to directories, not files.
@@ -3131,15 +3127,18 @@
       not affect what gets checked out as an external (though the
       relative local target subdirectory will, of course, move with
       renamed directory).  This can be confusing—even
-      frustrating—in certain situations.  For example, if you
-      use externals definitions on a directory in your
-      <filename>/trunk</filename> development line which point to
-      other areas of that same line, and then you use <command>svn
-      copy</command> to branch that line to some new location
+      frustrating—in certain situations.  For example, say you
+      have a top-level directory named <filename>project</filename>.
+      If you create an externals definition on one subdirectory of
+      your <filename>project</filename> directory which tracks the
+      latest revision of some other subdirectory of that same tree,
+      and then you use <command>svn move</command> to rename the
+      <filename>project</filename> directory
       <filename>/branches/my-branch</filename>, the externals
       definitions on items in your new branch will still refer to
-      versioned resources in <filename>/trunk</filename>.  Be aware,
-      too, that if you need to re-parent your working copy (using
+      versioned objects in the <filename>project</filename> directory,
+      even though that directory no longer exists.  Be aware, too,
+      that if you need to re-parent your working copy (using
       <command>svn switch --relocate</command>), externals definitions
       will <emphasis>not</emphasis> also be re-parented.</para>
 

Modified: trunk/src/ru/book/ch-fundamental-concepts.xml
==============================================================================
--- trunk/src/ru/book/ch-fundamental-concepts.xml	(original)
+++ trunk/src/ru/book/ch-fundamental-concepts.xml	Thu Jun 28 20:00:32 2007
@@ -656,14 +656,14 @@
       <!-- @ENGLISH {{{
       <para>In the second syntax, you need to quote the URL so that the
         vertical bar character is not interpreted as a pipe.  Also, note
-        that a URL uses ordinary slashes even though the native
+        that a URL uses forward slashes even though the native
         (non-URL) form of a path on Windows uses backslashes.</para>
       @ENGLISH }}} -->
       <para>При второй форме записи, для того, чтобы вертикальная черта 
         не расценивалась как канал, необходимо брать URL в кавычки. 
-        Так же обратите внимание на использование в URL обычной косой 
-        черты, не взирая на то, что родная (не-URL) форма записи пути на 
-        Windows использует обратную косую черту.</para>
+        Так же обратите внимание на использование в URL прямого слеша,
+        не взирая на то, что родная (не-URL) форма записи пути на 
+        Windows использует обратный слеш.</para>
 
       <!-- @ENGLISH {{{
       <para>Finally, it should be noted that the Subversion client will

Modified: trunk/src/ru/sync.py
==============================================================================
--- trunk/src/ru/sync.py	(original)
+++ trunk/src/ru/sync.py	Thu Jun 28 20:00:32 2007
@@ -98,6 +98,8 @@
       dry_run = True
     elif o == '-u':
       return update_status_file()
+  os.popen('mkdir book'+os.sep+'working')
+  os.system('cp book/*xml book/working')
   cmd = string.Template(
       'svn $a -r $r1:$r2 http://svn.red-bean.com/svnbook/trunk/src/en/book/$t')
   print ('########################################################################')




More information about the svnbook-dev mailing list