[svnbook commit] r3340 - trunk/src/ru/book

Imaged noreply at red-bean.com
Tue Oct 28 16:27:29 CDT 2008


Author: Imaged
Date: Tue Oct 28 16:27:29 2008
New Revision: 3340

Log:
 * ru/book/ch-branching-and-merging.xml: essential fixes of stylistics and spell checking

Modified:
   trunk/src/ru/book/ch-branching-and-merging.xml

Modified: trunk/src/ru/book/ch-branching-and-merging.xml
==============================================================================
--- trunk/src/ru/book/ch-branching-and-merging.xml	(original)
+++ trunk/src/ru/book/ch-branching-and-merging.xml	Tue Oct 28 16:27:29 2008
@@ -61,7 +61,7 @@
       <quote>адаптированном</quote> для них варианте, поскольку
       работа каждого подразделения имеет свою специфику.</para>
 
-    <para>Как вы поступите в такой ситуации? Очевидно, вы сделаете так:
+    <para>Как быть в такой ситуации? Скорее всего, вы 
       создадите вторую копию документа и начнёте отдельно сопровождать 
       обе копии. Когда какое-то из подразделений попросит вас
       внести небольшие изменения, вы включите их либо в первую копию, 
@@ -1214,11 +1214,11 @@
         two repository trees are compared, and the differences are
         applied to a working copy.</para>
       @ENGLISH }}} -->
-      <title>Ключевые понятия, стоящие за слиянием</title>
+      <title>Ключевые идеи, стоящие за слиянием</title>
 
-      <para>Вы увидели примеры использования <command>svn
-        merge</command>, так что настала пора разобраться поглубже. 
-        Если вы чувствуете неуверенность  в том как, собственно, 
+      <para>Теперь, после знакомства с примерами использования <command>svn
+        merge</command>, настала пора разобраться в них поглубже. 
+        Если вы чувствуете неуверенность в том как, собственно, 
         работает слияние, то вы в этом
         вы не одиноки. Многие пользователи (особенно те, для которых
         управление версиями в новинку) поначалу путаются в правильности
@@ -1267,7 +1267,7 @@
           называемое <firstterm>правой частью</firstterm> при
           сравнении),</para></listitem>
 
-        <listitem><para>Рабочую копию для применения отличий,
+        <listitem><para>Рабочую копию, к которой отличия применяются
           в виде локальных изменений (как правило, называемую
           <firstterm>целью</firstterm> слияния).</para></listitem>
 
@@ -1288,19 +1288,19 @@
         specify the three necessary arguments rather flexibly.  Here
         are some examples:</para>
       @ENGLISH }}} -->
-      <para>Когда эти три аргумента указаны, сравниваются два дерева
-        и результирующие различия применяются к целевой рабочей копии
-        в виде локальных изменений. После того, как команда выполнена,
-        результат не будет отличаться он того как если бы вы вручную
-        редактировали файлы или многократно выполняли команды
-        <command>svn add</command> или <command>svn delete</command>
-        самостоятельно. Если результат вас устраивает, его можно
+      <para>Когда эти три аргумента указаны, производится сравнение 
+        двух деревьев, а полученные различия применяются к целевой 
+        рабочей копии в виде локальных изменений. После выполнения 
+        этой команды результат будет так же, как в случае, если бы вы 
+        вручную редактировали файлы или многократно выполняли команды
+        <command>svn add</command> или <command>svn delete</command>. 
+        Если результат вас устраивает, его можно
         зафиксировать. Если результат вас не устраивает, просто
         отмените (<command>svn revert</command>) все сделанные
         изменения.</para>
 
-      <para>Правила записи <command>svn merge</command> позволяют
-        указывать три необходимых аргумента довольно гибко. Вот
+      <para>Синтаксис <command>svn merge</command> позволяет
+        указывать эти три аргумента довольно гибко. Вот
         несколько примеров:</para>
 
       <screen>      
@@ -1322,14 +1322,14 @@
         how the working-copy argument is optional; if omitted, it
         defaults to the current directory.</para>
       @ENGLISH }}} -->
-      <para>В первом примере записи все три аргумента явно указаны,
-        указываются деревья, в форме <emphasis>URL at REV</emphasis> и
-        указывается целевая рабочая копия. Второй пример записи может
-        использоваться для краткости записи, в ситуациях, когда
+      <para>В первом варианте все три аргумента указаны явно —
+        каждое дерево задано в форме <emphasis>URL at REV</emphasis> и
+        указана целевая рабочая копия. Второй вариант может
+        использоваться для краткости записи в ситуациях, когда
         сравниваются две разных правки по одному и тому же URL.
-        Последний пример демонстрирует возможность не указывать целевую
-        рабочую копию, при этом по умолчанию используется текущая
-        директория.</para>
+        Последний вариант демонстрирует возможность не указывать целевую
+        рабочую копию, при этом по умолчанию используется текущий
+        каталог.</para>
 
     </sect2>
 
@@ -1360,12 +1360,12 @@
           на практике могут возникнуть трудности. Проблема заключается
           в том, что при многократном объединении изменений одной
           ветки с другой можно непреднамеренно сделать объединение одних
-          и тех же изменений <emphasis>дважды</emphasis>. Иногда,
-          когда это случается, проблем это не вызывает. При внесении
-          изменений в файл, как правило Subversion предупреждает
-          о том что файл уже содержит изменения и в этом случае не
-          выполняет никаких действий. Однако если уже присутствующие
-          изменения были модифицированы, то возникнет конфликт.</para>
+          и тех же изменений <emphasis>дважды</emphasis>. Иногда
+          это не вызывает проблем. При применении изменений к файлу 
+          Subversion, как правило, предупреждает о том, что файл 
+          уже содержит изменения и в этом случае не
+          выполняет никаких действий. Однако, если уже присутствующие
+          изменения были модифицированы, возникнет конфликт.</para>
 
         <!-- @ENGLISH {{{
         <para>Ideally, your version control system should prevent the
@@ -1382,16 +1382,16 @@
           running <command>svn merge</command>, or from just
           hand-editing the files.</para>
         @ENGLISH }}} -->
-        <para>В идеале, система управления версиями должна предотвращать
+        <para>В идеале система управления версиями должна предотвращать
           повторное применение изменений к ветке. Она должна автоматически
           фиксировать, какие изменения уже были получены и иметь возможность
-          перечислить их вам. Должна использовать эту информацию для того,
-          чтобы, насколько возможно, помочь автоматизировать
+          перечислить их вам. Она должна использовать эту информацию 
+          для того, чтобы, насколько возможно, помочь автоматизировать
           слияние.</para>
 
         <para>К сожалению, Subversion не такая система. Как и
           CVS, Subversion пока не сохраняет никакой информации об
-          операциях объединения. При фиксации локальных изменений хранилище
+          операциях слияния. При фиксации локальных изменений хранилище
           понятия не имеет, являются ли эти изменения результатом
           выполнения команды <command>svn merge</command> или результатом
           обычного ручного редактирования файлов.</para>
@@ -1413,20 +1413,20 @@
         <para>In the next section, we'll show some examples of this
           technique in action.</para>
         @ENGLISH }}} -->
-        <para>Что это означает для вас, как пользователя? Это означает,
+        <para>Что это означает для вас как пользователя? Это означает,
           что до того момента, пока у Subversion не появится этой функции,
           вам придется контролировать слияние информации самостоятельно.
           Лучшим местом для этого является лог-сообщение. Как было
-          показано в предыдущих примерах, рекомендуется, что бы в
+          показано в предыдущих примерах, рекомендуется, чтобы в
           лог-сообщении был указан конкретный номер правки (или диапазон
-          правок) которые были слиты в вашу ветку. После этого, для того,
-          что бы просмотреть какие изменения ваша ветка уже содержит,
-          вы можете запустить команду <command>svn log</command>. Это
-          позволит быть аккуратнее при выполнении команды <command>svn
-          merge</command>, что бы не пересечься с уже портированными
-          изменениями.</para>
+          правок), которые были слиты в вашу ветку. В этом случае вы 
+          сможете впоследствии просмотреть, какие изменения уже содержит
+          ваша ветка, запусти команду <command>svn log</command>. Это
+          позволит быть осторожнее при последующих запусках команды 
+          <command>svn merge</command> и избежать пересечения с уже 
+          портированными изменениями.</para>
 
-        <para>В следующем разделе мы на примерах рассмотрим эту технику
+        <para>В следующем разделе мы на примерах рассмотрим эту методику
           в действии.</para>
 
       </sect3>
@@ -1446,19 +1446,19 @@
           <command>svn revert</command> is no longer an option.  The
           two sets of changes may be impossible to separate.</para>
         @ENGLISH }}} -->
-        <title>Предварительные просмотр при объединении</title>
+        <title>Предварительный просмотр результатов слияния</title>
 
-        <para>Учитывая, что результатом слияния являются локальные
-          модификации, такая операция не является опасной. Если
-          в начале, при выполнении объединения вы ошиблись, просто
-          отмените изменения (<command>svn revert</command>) и
-          попробуйте еще раз.</para>
+        <para>Поскольку результатом слияния являются локальные
+          изменения, такая операция не является опасной. Допустив
+          при слиянии ошибку, можно просто
+          отменить изменения (<command>svn revert</command>) и
+          попробовать еще раз.</para>
 
         <para>Однако, возможна ситуация, когда рабочая копия уже
           содержит локальные изменения. Изменения, примененные при
-          слиянии будут смешаны с уже существующими и
-          <command>svn revert</command> запустить будет нельзя.
-          Если нельзя будет разделить два набора изменений.</para>
+          слиянии, будут смешаны с уже существующими, и запуск
+          <command>svn revert</command> нас больше не устроит.
+          Разделить два множества изменений будет невозможно.</para>
 
         <!-- @ENGLISH {{{
         <para>In cases like this, people take comfort in being able to
@@ -1470,13 +1470,13 @@
           <option>-ﳢ-dry-run</option> option to the merge
           command:</para>
         @ENGLISH }}} -->
-        <para>В такой ситуации лучше будет попробовать спрогнозировать
-          или проверить объединения до того, как они произойдут.
-          Самым простым вариантом является запуск <command>svn diff</command>
-          с теми же аргументами, что и для <command>svn merge</command>,
-          это мы уже показывали в первом примере объединения. Другим
-          вариантом предпросмотра является передача команде объединения
-          опции <option>--dry-run</option>:</para>
+        <para>В такой ситуации лучше попробовать спрогнозировать
+          или проверить результат слияния до того, как оно произойдет.
+          Проще всего запустить для этого <command>svn diff</command>
+          с теми же аргументами, что и для <command>svn merge</command>.
+          Мы уже показывали это в первом примере объединения. Другим 
+          способом предварительного просмотра может служить вызов 
+          команды слияния с опцией <option>--dry-run</option>:</para>
 
         <screen>
 $ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
@@ -1495,13 +1495,13 @@
           times when running <command>svn diff</command> gives too
           much detail.</para>
         @ENGLISH }}} -->
-        <para>Опция <option>--dry-run</option> не вносит локальные
-          изменения в рабочую копию. Показываются только коды
-          статуса которые <emphasis>будут</emphasis> выведены
-          при настоящем объединении. Это полезно для получения
-          <quote>обобщенной</quote> информации об объединении
-          для тех случаев, когда запуск <command>svn diff</command>
-          выдает слишком детальную информацию.</para>
+        <para>Опция <option>--dry-run</option> позволяет не применять 
+          локальные изменения к рабочей копии. Она только показывает
+          статусы, которые <emphasis>имели бы</emphasis> файлы
+          при реальном объединении. Это полезно для получения
+          <quote>сводной</quote> информации о потенциальном слиянии
+          в тех случаях, когда запуск <command>svn diff</command>
+          выдает слишком много подробностей.</para>
 
       </sect3>
 
@@ -1527,20 +1527,21 @@
           delta is guaranteed to correctly convert your working copy
           into the right-hand tree.</para>
         @ENGLISH }}} -->
-        <title>Конфликты при объединении</title>
+        <title>Конфликты при слиянии</title>
 
-        <para>Так же как и команда <command>svn update</command>,
+        <para>Так же как и <command>svn update</command>, команда
           <command>svn merge</command> внедряет изменения в
-          рабочую копию. А следовательно тоже может создавать
-          конфликты. Однако конфликты, создаваемые <command>svn
-          merge</command> иногда отличаются и эти отличия
-          рассмотрены в этом разделе.</para>
+          рабочую копию. Следовательно, она тоже может создавать
+          конфликты. Однако конфликты, порождаемые <command>svn
+          merge</command>, имеют определенные отличия, и поэтому 
+          мы их сейчас рассмотрим подробнее.</para>
 
-        <para>В начале будем считать, что рабочая копия не имеет
+        <para>Вначале предположим, что рабочая копия не имеет
           локальных изменений. При обновлении (<command>svn
-          update</command>) до конкретной правки, изменения, отправляемые
-          сервером, будут всегда <quote>без проблем</quote> внедрятся
-          в рабочую копию. Сервер создает дельту сравнивая два дерева:
+          update</command>) рабочей копии до конкретной правки 
+          отправляемые сервером изменения будут всегда <quote>без 
+          проблем</quote> внедряться
+          в рабочую копию. Сервер создает дельту, сравнивая два дерева:
           виртуальный снимок рабочей копии и дерево файлов, которое
           вас интересует. Учитывая то, что левая часть сравнения
           полностью эквивалентна тому, что вы уже имеете, дельта
@@ -1561,17 +1562,17 @@
           <quote>failed hunks</quote>, <command>svn merge</command>
           will complain about <quote>skipped targets</quote>:</para>
         @ENGLISH }}} -->
-        <para>Однако <command>svn merge</command> не может этого
-          гарантировать и может вести себя более хаотично:
+        <para>Однако <command>svn merge</command> не дает такой
+          гарантии, и может вести себя более непредсказуемо:
           пользователь может запросить сервер сравнить
           <emphasis>любые</emphasis> два дерева файлов, даже такие,
           которые не имеют отношения к рабочей копии! Из этого
-          следует большое количество потенциальных человеческих
-          ошибок. Пользователи иногда будут сравнивать два
-          ошибочных дерева создавая дельту которая не
+          следует множество потенциальных человеческих
+          ошибок. Иногда пользователи будут сравнивать два
+          ошибочных дерева, создавая дельту, которая не
           сможет правильно внедриться. <command>svn
-          merge</command> будет пытаться внедрить по возможности
-          больше различий, но иногда это будет невозможно.
+          merge</command> будет пытаться внедрить различия
+          по максимуму, но иногда это будет невозможно.
           Так же как команда <command>patch</command> в Unix
           иногда жалуется на <quote>неудачные попытки</quote>
           объединения, <command>svn merge</command> будет
@@ -1618,22 +1619,22 @@
           дельту для того, чтобы изменить содержимое файла, однако в
           рабочей копии файл отсутствует. В любом случае сообщение
           <quote>skipped</quote> означает, что скорее всего пользователь
-          ошибся при указании деревьев для сравнения; классическая ошибка
-          оператора. Если это произошло, то проще всего рекурсивно
-          отменить все изменения, сделанные при слиянии (<command>svn
-          revert --recursive</command>), сразу же после этого удалить
-          все неверсионированные файлы и директории и повторно
-          запустить <command>svn merge</command> с другими
-          параметрами.</para>
+          ошибся при указании деревьев для сравнения — то есть это 
+          классическая ошибка оператора. Если это так, проще 
+          всего рекурсивно отменить все изменения, сделанные при слиянии 
+          (<command>svn revert --recursive</command>), сразу же после 
+          этого удалить все неверсионированные файлы и каталоги и 
+          повторно запустить <command>svn merge</command> с 
+          другими параметрами.</para>
 
         <para>Обратите внимание на то, что в предыдущем примере
           в файле <filename>glorb.h</filename> возник конфликт.
-          Ранее мы договорились, что рабочая копия не имеет
-          локальных изменений: откуда же взялся конфликт?
-          Опять же, так как пользователь мог запустить <command>svn
+          Откуда же он мог взяться, если ранее мы договорились, 
+          что рабочая копия не имеет локальных изменений?
+          Опять же, пользователь мог запустить <command>svn
           merge</command> для выделения и применения к рабочей копии
-          какой то старой дельты, в результате, такая дельта может
-          содержать изменения, которые не смогут внедриться в рабочий
+          какой то старой дельты. В результате такая дельта может
+          содержать изменения, которые нельзя внедрить в рабочий
           файл без появления проблем, даже если он не имеет локальных
           изменений.</para>
 
@@ -1657,24 +1658,24 @@
           update versus ones that happened as a result of a
           merge.</para>
         @ENGLISH }}} -->
-        <para>Еще одно небольшое отличием между <command>svn
+        <para>Еще одно небольшое отличие между <command>svn
           update</command> и <command>svn merge</command> заключается
-          в названиях файлов, создаваемых при возникновении конфликта.
+          в названиях файлов, создаваемых при конфликтах.
           В разделе <xref linkend="svn.tour.cycle.resolve"/> мы
           говорили о том, что при обновлении создаются файлы с
           названиями <filename>filename.mine</filename>,
-          <filename>filename.rOLDREV</filename>, и
+          <filename>filename.rOLDREV</filename> и
           <filename>filename.rNEWREV</filename>. А <command>svn
           merge</command> в конфликтной ситуации создает три файла
           с названиями <filename>filename.working</filename>,
           <filename>filename.left</filename> и
-          <filename>filename.right</filename>. Здесь, термины
-          <quote>left</quote> и <quote>right</quote> указывают
+          <filename>filename.right</filename>. Термины 
+          <quote>left</quote> и <quote>right</quote> указывают здесь
           на две стороны сравнения, то есть на используемые при
           сравнении деревья. Это разделение используемых названий
-          поможет вам отличать конфликты возникшие в результате
-          обновления от конфликтов, возникших в результате
-          объединения.</para>
+          поможет вам отличать конфликты, возникшие в результате
+          обновления, от конфликтов, возникших в результате
+          слияния.</para>
 
       </sect3>
 
@@ -1704,23 +1705,23 @@
         @ENGLISH }}} -->
         <title>Учитывать или игнорировать происхождение</title>
 
-        <para>При общении разработчиков, использующих Subversion
-          очень часто можно услышать упоминание термина
+        <para>Общаясь с разработчиками, использующими Subversion,
+          очень часто можно услышать термин
           <firstterm>происхождение</firstterm>. Это слово используется
           для описания отношений между двумя объектами хранилища:
-          если между ними есть связь, тогда говорят, что один объект
-          является предком другого.</para>
+          если между ними есть связь, то говорят, что один объект
+          происходит от другого.</para>
 
-        <para>Например, предположим, что фиксируется правка 100,
-          в которой содержатся изменения файла <filename>foo.c</filename>.
+        <para>Предположим, что фиксируется правка 100,
+          в которой изменяется файл <filename>foo.c</filename>.
           В этом случае файл <filename>foo.c at 99</filename> является предком
           файла <filename>foo.c at 100</filename>. С другой стороны, можно
           допустить, что в правке 101 вы фиксируете удаление
           <filename>foo.c</filename>, а затем в правке 102 добавляете
-          новый файл с таким же именем. В таком случае файлы
-          <filename>foo.c at 99</filename> и <filename>foo.c at 102</filename>
-          могут выглядеть так, как будто они имеют друг к другу отношение
-          (у них одинаковый путь), однако на самом деле являются
+          новый файл с таким же именем. В таком случае может показаться,
+          что файлы <filename>foo.c at 99</filename> и <filename>foo.c at 102</filename>
+          имеют отношение друг к другу (у них одинаковый путь), 
+          однако на самом деле они являются
           полностью независимыми объектами хранилища. Они не имеют
           ни общей истории, ни общих <quote>предков</quote>.</para>
 
@@ -1738,10 +1739,10 @@
           delete the old file, then add the new file;  the output would
           indicate a deletion followed by an add:</para>
         @ENGLISH }}} -->
-        <para>Мы обращаем на это ваше внимание, для того, чтобы
-          указать на важные отличия между <command>svn diff</command>
+        <para>Мы обращаем на это ваше внимание, чтобы
+          указать на важные различия между <command>svn diff</command>
           и <command>svn merge</command>. Первая команда игнорирует
-          происхождение, в то время, как вторая его учитывает.
+          происхождение, в то время как вторая его учитывает.
           Например, если попросить <command>svn diff</command> сравнить
           правки 99 и 102 файла <filename>foo.c</filename> вы увидите
           построчное сравнение; команда <literal>diff</literal> слепо сравнивает
@@ -1749,7 +1750,7 @@
           сравнить те же объекты, то Subversion предупредит вас о том, что
           они не связаны друг с другом и сначала попытается удалить
           старый файл, а затем добавить новый; вывод команды покажет
-	  удаление с последующим добавлением:</para>
+          удаление с последующим добавлением:</para>
 
         <screen>
 D  foo.c
@@ -1779,26 +1780,26 @@
           <command>svn diff</command> to behave like the
           <literal>merge</literal> command.)</para>
         @ENGLISH }}} -->
-        <para>В большинстве случаев при объединении сравниваются
+        <para>В большинстве случаев при слиянии сравниваются
           деревья, имеющие родственную связь и по умолчанию
           <command>svn merge</command> рассчитывает на это. Однако
-          иногда, вам будет нужно, что бы команда <literal>merge</literal>
-	  сравнила два не связанных дерева файлов. Например, у вас может быть
-          два импортированных дерева содержащих исходный код
-          релизов программных проектов от сторонних поставщиков
+          иногда вам будет нужно, чтобы команда <literal>merge</literal>
+          сравнила два независимых дерева файлов. Например, вы могли 
+          импортировать два дерева, содержащие исходный код
+          релизов программных проектов сторонних поставщиков
           (см. <xref linkend="svn.advanced.vendorbr"/>). Если попросить
           <command>svn merge</command> сравнить два эти дерева,
           вы увидите, что первое дерево будет полностью удалено,
           а затем будет полностью добавлено второе!</para>
 
-        <para>В подобных ситуациях вам нужно, чтобы команда
-          <command>svn merge</command> выполняла сравнение основанное
-          только на пути, без учета любых отношений между файлами
-          и директориями. Добавьте опцию <option>--ignore-ancestry</option>
-          при записи команды объединения, после чего эта команда будет
-          вести себя также как <command>svn diff</command>. (И наоборот,
-          опция <option>--notice-ancestry</option> будет заставлять
-          <command>svn diff</command> вести себя как команда
+        <para>В подобных ситуациях нужно, чтобы команда
+          <command>svn merge</command> выполняла сравнение, учитывая только 
+          пути, и не обращала внимание на отношения между файлами
+          и каталогами. Добавьте опцию <option>--ignore-ancestry</option>
+          при запуске команды слияния, после чего она будет
+          вести себя аналогично <command>svn diff</command>. (И наоборот,
+          опция <option>--notice-ancestry</option> заставит
+          <command>svn diff</command> работать подобно команде
           <literal>merge</literal>.)</para>
 
       </sect3>
@@ -1819,11 +1820,11 @@
       merge</command>, and this section describes the most common ones
       you're likely to run into.</para>
     @ENGLISH }}} -->
-    <title>Типовые примеры использования</title>
+    <title>Типовые примеры</title>
 
-    <para>Для ветвления и команды <command>svn merge</command>
-      существует множество применений, в этом раздели описаны наиболее
-      типичные из тех с которыми вы можете столкнуться.</para>
+    <para>Ветвлением и слиянием можно пользоваться по-разному. 
+      В этом разделе описываются наиболее типичные примеры, 
+      с которыми вам придется иметь дело.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.commonuses.wholebr">
@@ -1848,21 +1849,21 @@
       @ENGLISH }}} -->
       <title>Полное объединение двух веток</title>
 
-      <para>Что бы завершить наш текущий пример, заглянем немного
-        в перед. Предположим, прошло несколько дней и как в главную
-        линию разработки так и вашу личную ветку было внесено множество
-        изменений. Допустим, что работу над своей веткой вы завершили;
-        добавление функциональности или исправление ошибок наконец
-        закончено и теперь вы хотите объединить все изменения из своей
+      <para>Чтобы закончить с последним примером, заглянем немного
+        вперед. Предположим, что прошло несколько дней. И в главную
+        линию разработки, и вашу личную ветку за это время было внесено 
+        множество изменений. Допустим, что работу над своей веткой вы 
+        завершили. Новый функционал добавлен, ошибки исправлены, 
+        и теперь вы хотите объединить все изменения из своей
         ветки с главной линией разработки.</para>
 
-      <para>Как же в этом случае нужно использовать <command>svn
-        merge</command>? Помните о том, что эта команда сравнивает
-        два дерева и применяет различия к рабочей копии. Поэтому,
-        для того, что бы было к чему применять изменения, необходимо
+      <para>Как применить в этом случае <command>svn merge</command>? 
+        Помните о том, что эта команда сравнивает
+        два дерева и применяет различия к рабочей копии. Следовательно,
+        для того, чтобы было к чему применять изменения, необходимо
         иметь рабочую копию главной линии разработки. Будем считать,
-        что-либо у вас под рукой имеется такая (полностью обновленная)
-        копия, либо вы только что создали новую рабочую копию
+        что такая, полностью обновленная копия у вас либо уже есть, 
+        либо вы ее только что создали в каталоге
         <filename>/calc/trunk</filename>.</para>
 
       <!-- @ENGLISH {{{
@@ -1888,27 +1889,27 @@
         branch directory, and apply those differences to a working
         copy of the trunk.</para>
       @ENGLISH }}} -->
-      <para>А какие именно два дерева должны сравниваться? На первый
-        взгляд ответ очевиден: сравнивать последнее дерево главной
+      <para>Но какие именно два дерева нужно сравнивать? На первый
+        взгляд ответ очевиден: нужно сравнить последнее дерево главной
         линии разработки с последним деревом вашей ветки. Однако
-        будьте осторожны — такое предположение является
-        <emphasis>ошибочным</emphasis>, многие новые пользователи
-        ошибаются подобным образом! Учитывая то, что <command>svn
-        merge</command> работает так же как <command>svn diff</command>,
-        сравнение последние версии главной линии разработки и вашей ветки
-        покажет изменения сделанные <emphasis>не</emphasis> только в вашей
-        ветке. Такое сравнение покажет слишком много изменений: будут
-        показано не только то, что добавлялось в вашей ветке,
+        такое предположение будет <emphasis>ошибочным</emphasis>.
+        Это типичная ошибка большинства новичков! 
+        Поскольку <command>svn merge</command> работает так же как и 
+        <command>svn diff</command>,
+        сравнение последней версии главной линии разработки и вашей ветки
+        покажет изменения, сделанные <emphasis>не</emphasis> только в вашей
+        ветке. Такое сравнение покажет слишком много изменений. Оно выведет
+        не только то, что добавлялось в вашей ветке,
         но и то, что <emphasis>удалялось</emphasis> в главной линии
         разработки и не удалялось в вашей ветке.</para>
 
-      <para>Для выделения только тех изменений, которые были сделаны
+      <para>Чтобы выделить только те изменения, которые были сделаны
         в вашей ветке, нужно сравнивать начальное и конечное состояния
-        ветки. Воспользовавшись <command>svn log</command> для ветки,
-        можно узнать, что она была создана в правке 341. А для определения
+        этой ветки. Посмотрев <command>svn log</command>,
+        можно узнать, что ветка была создана в правке 341. В качестве
         конечного состояния ветки можно просто использовать правку
         <literal>HEAD</literal>. Это значит, что вам нужно сравнить
-        правки 341 и <literal>HEAD</literal> директории с веткой и применить
+        правки 341 и <literal>HEAD</literal> каталога с веткой и применить
         различия к рабочей копии главной линии разработки.</para>
 
       <!-- @ENGLISH {{{
@@ -1927,16 +1928,16 @@
         <para>So in our continuing example,</para>
       @ENGLISH }}} -->
       <tip>
-        <para>Удобно для определения правки, в которой ветка была создана
-          (<quote>базовой</quote> правки ветки) использовать параметр
-          <option>--stop-on-copy</option> при запуске <command>svn
-          log</command>. При обычном запуске, эта команда показывает
-          все изменения сделанные в ветке, включая те, которые были
-          сделаны до создания ветки. Поэтому, при таком запуске
-          вы увидите и историю главной линии разработки. Параметр
-          <option>--stop-on-copy</option> остановит вывод лог сообщений
-          как только <command>svn log</command> определит, что
-          целевой объект был скопирован или переименован.</para>
+        <para>Для определения правки, в которой была создана ветка
+          (<quote>базовой</quote> правки ветки), удобно использовать 
+          параметр <option>--stop-on-copy</option> команды <command>svn
+          log</command>. Обычно эта команда показывает все изменения,
+          сделанные в ветке, включая те, которые были
+          сделаны до создания ветки. Поэтому вы будете видеть и историю 
+          главной линии разработки. Параметр
+          <option>--stop-on-copy</option> остановит вывод лог-сообщений,
+          как только <command>svn log</command> обнаружит
+          факт копирования или переименования целевого объекта.</para>
 
         <screen>
 $ svn log --verbose --stop-on-copy \
@@ -1956,16 +1957,15 @@
           was created by copying.</para>
       </tip>
       @ENGLISH }}} -->
-        <para>Как и ожидалось, последняя правка выведенная этой командой
-          будет правка, в которой директория
-          <filename>my-calc-branch</filename> была создана
-          путем копированием.</para>
+        <para>Как и ожидалось, последней строчкой эта команда
+          выведет ту правку, в которой в результате копирования был 
+          создан каталог <filename>my-calc-branch</filename>.</para>
       </tip>
 
       <!-- @ENGLISH {{{
       <para>Here's the final merging procedure, then:</para>
       @ENGLISH }}} -->
-      <para>Вот так выглядит завершение объединения:</para>
+      <para>Теперь мы можем завершить объединение веток:</para>
 
       <screen>
 $ cd calc/trunk
@@ -2013,27 +2013,27 @@
         trunk, and look for a log message about the last time you
         merged from the branch:</para>
       @ENGLISH }}} -->
-      <para>Еще раз обратите внимание, на то, что в лог сообщении
+      <para>Еще раз обратите внимание на то, что в лог-сообщении
         фиксации очень точно указан диапазон правок, которые были
         объединены с главной линией разработки. Никогда не забывайте
         этого делать, потому что это очень важная информация, которая
         понадобиться вам позже.</para>
 
-      <para>Например, предположим, что на следующей неделе вы решите
-        продолжить работу над веткой, для завершения расширения
-        функциональности или исправления ошибки. После этого, правка
-        <literal>HEAD</literal> хранилища будет имеет номер 480 и вы готовы
-        выполнить еще одно объединение своей личной копии с главной линией
+      <para>Предположим, что на следующей неделе вы решили 
+        продолжить работу над своей веткой, чтобы доработать новый 
+        функционал или исправить еще несколько ошибок. Теперь правка
+        <literal>HEAD</literal> хранилища имеет номер 480, и вы готовы
+        еще раз объединить свою личную копию с главной линией
         разработки. Однако, как уже было сказано в разделе
-        <xref linkend= "svn.branchmerge.copychanges.bestprac"/>, нет
-        необходимости объединять изменения которые уже были объединены
-        раньше; нужно объединить только <quote>новые</quote> изменения,
-        появившиеся с момента последнего объединения. Сложность в том,
-        что бы выделить эти новые изменения.</para>
-
-      <para>Первым шагом является запуск <command>svn log</command>
-        для главной линии разработки, для того, что бы увидеть
-        сообщение о времени последнего объединения с веткой:</para>
+        <xref linkend= "svn.branchmerge.copychanges.bestprac"/>, ранее
+        объединенные изменения не стоит объединять повторно.
+        Объединению подлежат только <quote>новые</quote> изменения,
+        появившиеся с момента последнего объединения. Сложность заключается
+        в том, чтобы выделить эти новые изменения.</para>
+
+      <para>Первым шагом будет запуск <command>svn log</command>
+        для главной линии разработки, в результате чего мы узнаем
+        время последнего объединения с веткой:</para>
 
       <screen>
 $ cd calc/trunk
@@ -2054,11 +2054,11 @@
         branch changes after that—by comparing revisions 406 and
         <literal>HEAD</literal>.</para>
       @ENGLISH }}} -->
-      <para>Ага! Так как все изменения в ветке, которые делались между
-        правками 341 и 405 уже были объединены с главной линией разработки
-        в правке 406, то теперь вы знаете, что необходимо брать только те
-        изменения ветки, которые были выполнены после этого —
-        сравнивая правки 406 и <literal>HEAD</literal>.</para>
+      <para>Ага! Все изменения ветки, сделанные между
+        правками 341 и 405, уже были объединены с главной линией разработки
+        в правке 406. Поэтому сейчас нам нужно взять только 
+        изменения, выполненные после этого. Для этого мы будем сравнивать
+        правки 406 и <literal>HEAD</literal>.</para>
 
       <screen>
 $ cd calc/trunk
@@ -2088,10 +2088,10 @@
         merges.</para>
       @ENGLISH }}} -->
       <para>Теперь главная линия разработки полностью содержит вторую
-        волну изменений, сделанных в ветке. С этого момента можно
+        волну изменений, сделанных в ветке. Теперь можно
         либо удалить ветку (об этом мы поговорим позже), либо
-        продолжать работать над веткой, с последующим объединением
-        изменений.</para>
+        продолжить работу над ней, периодически повторяя при этом 
+        процедуру объединения.</para>
 
     </sect2>
 
@@ -2114,17 +2114,16 @@
       @ENGLISH }}} -->
       <title>Отмена изменений</title>
 
-      <para>Еще одним типичным применением для <command>svn
-        merge</command> является откат изменений, которые уже были
-        зафиксированы. Предположим вы спокойно работаете в рабочей
-        копии <filename>/calc/trunk</filename> и выясняете, что
-        изменения сделанные в правке 303, которые изменили
-        <filename>integer.c</filename>, полностью ошибочны. Вы можете
+      <para>Еще одной типичной задачей для <command>svn
+        merge</command> является откат ранее сделанных изменений. 
+        Предположим, работая в копии <filename>/calc/trunk</filename>,
+        вы вдруг выясняете, что изменения файла <filename>integer.c</filename>,
+        сделанные в правке 303, были совершенно ошибочными. Вы можете
         воспользоваться командой <command>svn merge</command> для
         <quote>отмены</quote> изменений в своей рабочей копии,
         после чего зафиксировать локальные изменения в хранилище.
-        Все, что нужно сделать, это указать
-        <emphasis>обратные</emphasis> отличия:</para>
+        Для этого нужно всего лишь указать различия в
+        <emphasis>обратном порядке</emphasis>:</para>
 
       <screen>
 $ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
@@ -2155,13 +2154,13 @@
         changeset #303 to our working copy
         <emphasis>backwards</emphasis>.</para>
       @ENGLISH }}} -->
-      <para>Одним из взглядов на правку хранилища является представление
-        ее в виде сгруппированных изменений (некоторые системы управления
-        версиями называют это <firstterm>набором изменений</firstterm>).
-        Используя параметр <option>-r</option> можно попросить
+      <para>Правку хранилища можно рассматривать как группу изменений 
+        (некоторые системы управления версиями называют 
+        это <firstterm>набором изменений</firstterm>).
+        Используя параметр <option>-r</option>, можно попросить
         <command>svn merge</command> применить к рабочей копии набор
-        изменений или целый диапазон наборов изменений. В нашем случае
-        с отменой изменений, мы просим <command>svn merge</command>
+        изменений или целый диапазон наборов изменений. В нашем примере
+        с отменой изменений мы просим <command>svn merge</command>
         применить к рабочей копии набор изменений #303
         <emphasis>в обратном направлении</emphasis>.</para>
 
@@ -2182,16 +2181,16 @@
         @ENGLISH }}} -->
         <title>Subversion и наборы изменений</title>
 
-        <para>У каждого найдется свое, немного отличающееся
-          определение <quote>набора изменений</quote>, или во всяком
-          случая того, что это должно означать применительно к системе
-          управления версиями <quote>поддерживающей наборы
-          изменений</quote>. Для нашего случая будем считать, что
-          набор изменений это просто модификации объединенные под
+        <para>У каждого найдется свое собственное
+          определение <quote>набора изменений</quote>, или по крайней 
+          мере того, что должна уметь система
+          управления версиями, <quote>поддерживающая наборы
+          изменений</quote>. В нашем случае будем считать, что
+          набор изменений — это просто изменения, объединенные неким
           уникальным именем. Изменения могут заключаться в редактировании
           текста файлов, модификации структуры файлов или корректировке
-          метаданных. Проще говоря, набор изменений это просто патч
-          с заданным для него именем.</para>
+          метаданных. Проще говоря, набор изменений — это просто 
+          патч, идентифицируемый некоторым именем.</para>
 
         <!-- @ENGLISH {{{
         <para>In Subversion, a global revision number N names a tree
@@ -2215,22 +2214,22 @@
         @ENGLISH }}} -->
         <para>В Subversion глобальный номер правки N относится к
           дереву в хранилище: так выглядит хранилище после
-          фиксации N. Кроме того, это имя для неявного набора
+          фиксации N. Кроме того, это имя неявного набора
           изменений: если сравнить дерево N с деревом N-1 вы получите
           полный патч того, что было зафиксировано. В этом смысле,
           о <quote>правке N</quote> можно думать не как о дереве
           файлов, а как о наборе изменений. Если вы пользуетесь
           системой отслеживания релизов для управления ошибками,
-          вы можете использовать номера правок для того, что бы
+          вы можете использовать номера правок для того, чтобы
           ссылаться на конкретные патчи, которые исправляют
           ошибку — например, <quote>этот релиз был исправлен
-          правкой 9238.</quote>. После этого, для того, что бы прочитать
-          о том наборе изменений, который исправляет ошибку можно выполнить
-          <command>svn log -r9238</command>, а для того, что бы увидеть
-          сам патч, выполнить <command>svn diff -r9237:9238</command>.
-          В Subversion команда <literal>merge</literal> тоже использует
+          правкой 9238.</quote>. Тогда, чтобы узнать набор изменений, 
+          исправляющий заданную ошибку, можно выполнить
+          <command>svn log -r9238</command>, а чтобы увидеть
+          сам патч — запустить <command>svn diff -r9237:9238</command>.
+          Команда <literal>merge</literal> тоже использует
           номера правок. Можно объединить набор изменений из одной ветки
-          в другую указав его в качестве аргумента:
+          в другую, указав его в качестве аргумента:
           команда <command>svn merge -r9237:9238</command> внедрит
           набор изменений #9238 в вашу рабочую копию.</para>
 
@@ -2246,16 +2245,15 @@
         committing, this particular changeset is no longer reflected
         in the <literal>HEAD</literal> revision.</para>
       @ENGLISH }}} -->
-      <para>Обратите внимание, что откат изменений подобным образом
-        ничем не отличается от любых других операций, выполненных с
-        помощью <command>svn merge</command>, поэтому необходимо
-        использовать <command>svn status</command> и <command>svn
-         diff</command> для того, чтобы убедиться, что ваша
-         работа находится в том состоянии, в котором вам нужно, а затем,
-         используя <command>svn commit</command>, отправить финальную
-         версию в хранилище. После фиксации этот конкретный набор
-         изменений больше не будет отражен в правке
-         <literal>HEAD</literal>.</para>
+      <para>Обратите внимание, что подобный откат изменений 
+        ничем не отличается от остальных операций, выполняемых  с
+        помощью <command>svn merge</command>. Поэтому необходимо
+        с помощью <command>svn status</command> и <command>svn
+        diff</command> убедиться в том, что результат соответствует 
+        ожиданиям, а затем, используя <command>svn commit</command>, 
+        отправить финальную версию в хранилище. После фиксации 
+        этот конкретный набор изменений больше не будет отражен 
+        в правке <literal>HEAD</literal>.</para>
 
       <!-- @ENGLISH {{{
       <para>Again, you may be thinking: well, that really didn't undo
@@ -2289,29 +2287,29 @@
         </footnote>
       </para>
       @ENGLISH }}} -->
-      <para>Но наряду с этим, вы можете подумать: однако же на самом деле
-        фиксация не отменяется, не так ли? Изменения продолжают существовать
-        в правке 303. И если кто-то создаст рабочую копию версии проекта
-        <filename>calc</filename> между правками 303 и 349, он все равно
-        получит ошибочные изменения, верно?</para>
-
-      <para>Да, это так. Когда мы говорим об <quote>удалении</quote>
-        изменений, имеется в виду их удаление из <literal>HEAD</literal>.
-        Первоначальные изменения продолжают существовать в истории
-        хранилища. Для большинства ситуаций это является положительным
-        моментом. В любом случае, большинство пользователей интересует
-        только <literal>HEAD</literal> проекта. Однако, возможны
-        ситуации, когда действительно необходимо удалить последствия
-        фиксации. (Возможно, кто-то случайно зафиксировал
-        конфиденциальный документ.) Сделать это будет не так просто, так как
-        Subversion спроектирована специально таким образом, что бы исключить
-        возможность потери информации. Правки представляют собой не меняющиеся
-        деревья файлов, основывающиеся одно на другом. Удаление правки из
-        хранилища может вызвать эффект домино, создавая беспорядок во всех
-        последующих правках и возможно разрушая все рабочие копии.
-        <footnote><para>Однако, проект Subversion планирует со временем
-        реализовать команду <command>svnadmin obliterate</command>
-        с помощью которой можно будет выборочно удалять информацию.
+      <para>Давайте, однако, подумаем: отменяется ли на самом деле 
+        предыдущая фиксация? Изменения продолжают существовать
+        в правке 303. И если кто-то создаст рабочую копию проекта
+        <filename>calc</filename> между правками 303 и 349, он ведь 
+        все равно получит ошибочные изменения?</para>
+
+      <para>Безусловно, это так. Говоря об <quote>удалении</quote>
+        изменений, мы имеем в виду их удаление из правки <literal>HEAD</literal>.
+        Исходные изменения по-прежнему останутся в истории
+        хранилища. Чаще всего это можно рассматривать даже как 
+        положительный момент. В любом случае, большинство пользователей 
+        интересует только <literal>HEAD</literal>-правка проекта. 
+        Однако, возможны ситуации, когда необходимо полностью удалить 
+        последствия фиксации. (Например, если кто-то случайно зафиксировал
+        конфиденциальный документ.) Сделать это будет непросто, так как
+        архитектура Subversion намеренно исключает возможность потери 
+        информации. Правки представляют собой не меняющиеся
+        деревья файлов, основанные друг на друге. Удаление правки из
+        хранилища может вызвать эффект домино, потащив за собой все
+        последующие правки и повредив все рабочие копии.
+        <footnote><para>Однако, разработчики Subversion в будущем планируют
+        реализовать команду <command>svnadmin obliterate</command>,
+        которая позволит полностью удалять информацию.
         А пока за возможным решением проблемы обратитесь к разделу <xref
         linkend="svn.reposadmin.maint.tk.svndumpfilter"/>.</para>
         </footnote></para>
@@ -2342,22 +2340,21 @@
     <sect2 id="svn.branchmerge.commonuses.resurrect">
       <title>Восстановление удаленных элементов</title>
 
-      <para>Отличным свойством системы контроля версий является то,
+      <para>Отличным свойством системы управления версиями является то,
         что информация никогда не теряется. При удалении файла
-        или директории, элемент исчезает из правки <literal>HEAD</literal>
-        но продолжает существовать в более ранних правках. Одним
-        из наиболее частых вопросов, задаваемых новыми пользователями,
-        является такой: <quote>Как мне вернуть назад свой файл или
-        директорию?</quote></para>
-
-      <para>Первым шагом является определение того, <emphasis
-        role="bold">какой именно</emphasis> элемент вы пытаетесь
-        восстановить. Неплохой метафорой является представление
-        каждого объекта в хранилище существующим в двухмерной системе
-        координат. Первой координатой является отдельное дерево правок,
-        второй координатой является путь в этом дереве. Таким образом
-        каждая версия файла или директории может быть представлена
-        конкретной парой координат.</para>
+        или каталога элемент исключается из правки <literal>HEAD</literal>,
+        но продолжает существовать в более ранних правках. Новые пользователи
+        очень часто спрашивают: <quote>Как мне вернуть назад свой файл или
+        каталог?</quote></para>
+
+      <para>Для начала было бы неплохо определиться, <emphasis
+        role="bold">какой именно</emphasis> элемент мы пытаемся
+        восстановить. Для этого полезно представить все объекты 
+        хранилища как точки в двумерной системе координат. 
+        Первой координатой будет отдельное дерево правок,
+        в второй — путь в этом дереве. Таким образом,
+        каждая версия файла или каталога может быть задана
+        парой координат.</para>
 
       <!-- @ENGLISH {{{
       <para>Subversion has no <filename>Attic</filename> directory
@@ -2378,22 +2375,23 @@
         to examine the log output (via <command>grep</command>, or
         perhaps via an incremental search in an editor).</para>
       @ENGLISH }}} -->
-      <para>Subversion, в отличие от CVS, не имеет директории
+      <para>В отличие от CVS, Subversion не имеет каталога
         <filename>Attic</filename><footnote><para>Из-за того, что
         CVS не версионирует деревья, она создает область
-        <filename>Attic</filename> для каждой директории хранилища
-        как способ запоминания удаленных файлов.</para></footnote>
-        поэтому для определения необходимой при восстановлении пары
-        координат нужно воспользоваться командой <command>svn
-        log</command>. Лучше всего запустить <command>svn log
-        --verbose</command> в директории, которая содержала
-        удаленный элемент. Параметр <option>--verbose</option>
-        покажет для каждой правки список измененных элементов;
-        все, что вам остается сделать, это найти правку, в которой
-        файл или директория были удалены. Сделать это можно
-        визуально или воспользоваться для обработки вывода каким-то
-        инструментом (<command>grep</command> или может быть
-        последовательным поиском в редакторе).</para>
+        <filename>Attic</filename> для каждого каталога хранилища
+        как способ сохранения информации об удаленных 
+        файлах.</para></footnote>,
+        поэтому для определения искомой пары координат восстанавливаемого
+        объекта нужно вызвать <command>svn log</command>. 
+        Лучше всего запустить <command>svn log
+        --verbose</command> в каталоге, который содержал
+        удаленный объект. Параметр <option>--verbose</option>
+        покажет для каждой правки список измененных элементов —
+        в этом случае вам останется только найти ту правку, в которой
+        файл или каталог были удалены. Это можно сделать
+        визуально или обработав вывод команды каким-нибудь
+        инструментом (например, утилитой <command>grep</command> или 
+        просто запустив поиск в редакторе).</para>
 
       <screen>
 $ cd parent-dir
@@ -2432,25 +2430,25 @@
         The file would be scheduled for addition, and after a commit,
         the file would again exist in <literal>HEAD</literal>.</para>
       @ENGLISH }}} -->
-      <para>В примере предполагается, что вы ищите удаленный файл
-        <filename>real.c</filename>. Просмотрев логи родительской
-        директории вы определите, что этот файл был удален в правке
-        808. Следовательно, последняя существовавшая версия файла
-        была в правке, предшествующей этой. Вывод: необходимо из
+      <para>В этом примере предполагается, что вы ищете удаленный файл
+        <filename>real.c</filename>. Просмотрев логи родительского
+        каталога, вы можете заметить, что этот файл был удален в правке
+        808. Следовательно, самая последняя версия этого файла
+        была в правке, предшествующей удалению. Вывод: необходимо из
         правки 807 восстановить путь
         <filename>/calc/trunk/real.c</filename>.</para>
 
-      <para>Поиск был сложной задачей. Теперь, когда известно, что
-        нужно восстановить, есть две возможности.</para>
+      <para>Поиск — непростая задача. Теперь, когда нам известно, 
+        что именно нужно восстановить, есть две варианта действий.</para>
 
-      <para>Одним из вариантов является использование <command>svn
-        merge</command> для применения правки 808 <quote>в обратном
-        направлении</quote>. (Как отменять изменения мы уже рассматривали,
+      <para>Во-первых, мы можем посредством <command>svn merge</command> 
+        применить правку 808 <quote>в обратном
+        направлении</quote>. (Как отменять изменения, мы уже рассматривали,
         см. <xref linkend="svn.branchmerge.commonuses.undo"/>.) Это
-        приведет к эффекту повторного добавления фала
-        <filename>real.c</filename> в виде локальных изменений.
-        Файл будет запланирован для добавления и после фиксации
-        будет опять присутствовать в <literal>HEAD</literal>.</para>
+        приведет к повторному добавлению файла
+        <filename>real.c</filename> в форме локального изменения.
+        Файл будет запланирован для добавления, и после фиксации
+        будет снова присутствовать в <literal>HEAD</literal>.</para>
 
       <!-- @ENGLISH {{{
       <para>In this particular example, however, this is probably not
@@ -2470,20 +2468,20 @@
         revision and path <quote>coordinate pair</quote> from the
         repository to your working copy:</para>
       @ENGLISH }}} -->
-      <para>Однако в этом, отдельно взятом примере, это не самое лучшее
+      <para>Однако, в данном примере это не самое лучшее
         решение. Повторное применение правки 808 не только добавит
-        файл <filename>real.c</filename>; лог сообщение показывает, что
+        файл <filename>real.c</filename>. Лог-сообщение показывает, что также
         будут отменены некоторые изменения в <filename>integer.c</filename>,
-        чего вы не хотите. Конечно, можно выполнить обратное объединение
+        что весьма нежелательно. Конечно, можно выполнить обратное слияние 
         с правкой 808, а затем отменить (<command>svn revert</command>)
-        локальные изменения <filename>integer.c</filename>, однако такой
-        подход плохо масштабируется. Что если в правке 808 было изменено
+        локальные изменения в <filename>integer.c</filename>, но такой
+        подход плохо масштабируется. Что, если в правке 808 изменилось
         90 файлов?</para>
 
-      <para>При втором, более целевом методе, <command>svn merge</command>
+      <para>При другом, более аккуратном подходе <command>svn merge</command>
         вообще не используется, а вместо этого применяется команда
-        <command>svn copy</command>. Просто скопируете определенные
-        <quote>парой координат</quote> правку и путь из хранилища в
+        <command>svn copy</command>. Просто скопируйте объект, заданный 
+        <quote>парой координат</quote> (правка и путь), из хранилища в
         рабочую копию:</para>
 
       <screen>
@@ -2514,19 +2512,18 @@
         that these same techniques work just as well for resurrecting
         deleted directories.</para>
       @ENGLISH }}} -->
-      <para>Знак плюс в статусе показывает, что элемент не просто
-        запланирован для добавления, а запланирован для добавления
-        <quote>с историей</quote>. Subversion запоминает откуда он был
-        скопирован. В будущем, запуск <command>svn log</command> для
-        этого файла будет пересекать восстановление файла и всю историю,
-        предшествующую правке 807. Другими словами, новый файл
-        <filename>real.c</filename> на самом деле не является новым;
-        он является прямым наследником оригинального, удаленного
-        файла.</para>
-
-      <para>Хотя наш пример показывает как восстанавливать файл, обратите
-        внимание, на то что этот подход работает также и для
-        восстановления удаленных директорий.</para>
+      <para>Знак "плюс" в столбце статуса показывает, что 
+        элемент не просто запланирован для добавления, а запланирован 
+        для добавления <quote>с историей</quote>. Subversion запоминает, 
+        откуда он был скопирован. В будущем вызов <command>svn log</command> 
+        для этого файла будет пересекать точку восстановления файла и 
+        прослеживать всю историю, предшествующую правке 807. Другими словами, 
+        новый файл <filename>real.c</filename> на самом деле не является новым;
+        он является прямым потомком исходного файла, который был удален.</para>
+
+      <para>Хотя наш пример демонстрирует только восстановление файла,
+        отметим, что такой же подход будет работать и при 
+        восстановлении удаленных каталогов.</para>
 
     </sect2>
 
@@ -2547,20 +2544,20 @@
         Still, it may help to see them described in Subversion
         terms.</para>
       @ENGLISH }}} -->
-      <title>Типовые приемы при использовании веток</title>
+      <title>Типовые приемы использования веток</title>
 
       <para>Управление версиями чаще всего используется при
         разработке программного обеспечения, поэтому здесь мы
-        вкратце рассмотрим два, наиболее часто используемые командами
-        программистов, приема ветвления/слияния. Если вы не используете
+        вкратце рассмотрим два наиболее часто используемых командами
+        программистов приема ветвления/слияния. Если вы не используете
         Subversion для разработки программного обеспечения, можете
-        пропустить этот раздел. Если вы разработчик программного
-        обеспечения использующий контроль версий впервые, внимательно
-        присмотритесь, поскольку опытные разработчики считают использование
-        этих приемов хорошим стилем работы. Такие приемы не являются
-        специфичными для Subversion; они применимы к любой системе
-        управления версиями. Тем более, что это поможет увидеть
-        их описание в терминах Subversion.</para>
+        пропустить этот раздел. Если вы — разработчик программного
+        обеспечения, впервые использующий контроль версий, уделите этому
+        разделу пристальное внимание, поскольку опытные разработчики 
+        считают использование данных приемов хорошим стилем. 
+        Такие приемы не являются специфичными для Subversion; 
+        они применимы к любой системе управления версиями. 
+        Однако, здесь мы взглянем на них с позиций Subversion.</para>
 
       <sect3 id="svn.branchmerge.commonuses.patterns.release">
         <!-- @ENGLISH {{{




More information about the svnbook-dev mailing list