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

dmitriy svnbook-dev at red-bean.com
Sat Aug 13 01:09:56 CDT 2005


Author: dmitriy
Date: Sat Aug 13 01:09:54 2005
New Revision: 1603

Modified:
   trunk/src/ru/Makefile
   trunk/src/ru/book/ch00.xml   (contents, props changed)
   trunk/src/ru/book/ch02.xml
   trunk/src/ru/book/ch03.xml
   trunk/src/ru/book/ch04.xml
   trunk/src/ru/sync.py
Log:
* ru/sync.py
  Since command shell on Windows doesn't understand escape-sequences,
  therefore I have removed a color output on Windows

* ru/book/ch00.xml: sync r1575:r1591, against en/

* ru/book/ch02.xml: finishing translation of svn.basic.in-action.mixedrevs

* ru/book/ch03.xml
* ru/Makefile
  Tweaks

* ru/book/ch04.xml: adding translation for 
  svn.branchmerge.copychanges.bestprac


Modified: trunk/src/ru/Makefile
==============================================================================
--- trunk/src/ru/Makefile	(original)
+++ trunk/src/ru/Makefile	Sat Aug 13 01:09:54 2005
@@ -7,4 +7,4 @@
 L10N_REVISION = в редакции
 
 dist-html-chunk:
-	../tools/book-dist.py --html-chunk --name svnbook-html-chunk-ru
+	../tools/book-dist.py --html-chunk

Modified: trunk/src/ru/book/ch00.xml
==============================================================================
--- trunk/src/ru/book/ch00.xml	(original)
+++ trunk/src/ru/book/ch00.xml	Sat Aug 13 01:09:54 2005
@@ -72,7 +72,7 @@
     мощное, удобное и гибкое средство.</para>
 
     <!-- @ENGLISH {{{
-    <para>This book is written to document the 1.1 series of the
+    <para>This book is written to document the 1.2 series of the
       Subversion version control system.  We have made every attempt to be
       thorough in our coverage.  However, Subversion has a thriving
       and energetic development community, so there are already a
@@ -82,7 +82,7 @@
     </para>
     @ENGLISH }}} -->
     <para>Эта книга описывает систему управления версиями Subversion
-      поколения 1.1. Мы стремились охватить материал как можно шире.
+      поколения 1.2. Мы стремились охватить материал как можно шире.
       В то же время следует иметь в виду, что разработкой Subversion
       занимается активное энергичное сообщество, так что уже сейчас идёт
       работа над рядом особенностей и улучшений, которые будут внесены в

Modified: trunk/src/ru/book/ch02.xml
==============================================================================
--- trunk/src/ru/book/ch02.xml	(original)
+++ trunk/src/ru/book/ch02.xml	Sat Aug 13 01:09:54 2005
@@ -1392,6 +1392,7 @@
         </sect3>
 
         <sect3 id="svn.basic.in-action.mixedrevs.normal">
+          <!-- @ENGLISH {{{
           <title>Mixed revisions are normal</title>
 
           <para>The fact is, <emphasis>every time</emphasis> you
@@ -1403,7 +1404,7 @@
             mixture of revisions.  Even if you're the only person
             using the repository, you will still see this phenomenon.
             To examine your mixture of working revisions, use
-            the <command>svn status --verbose</command> command (see
+            the <command>svn status -ﳢ-verbose</command> command (see
             <xref linkend="svn.tour.cycle.examine.status"/> for more
             information.)</para>
 
@@ -1421,9 +1422,39 @@
             long time), then the history of
             the <emphasis>older</emphasis> version of the object is
             shown.</para>
+          @ENGLISH }}} -->
+          <title>Смешивание правок это нормально</title>
+
+          <para>Фактически, <emphasis>каждый раз</emphasis>, при
+            выполнении <command>svn commit</command>, правки рабочей
+            копии смешиваются. Только что зафиксированые элементы
+            отмечаются как имеющие большую рабочую правку чем все
+            остальные. После нескольких фиксаций (без выполнения
+            обновлений между ними) правки рабочей копии будут полностью
+            перемешаны. Даже если вы являетесь единственым пользователем
+            хранилища, вы все равно с этим столкнетесь. Для просмотра
+            этой смеси рабочих правок воспользуйтесь командой
+            <command>svn status --verbose</command> (см.
+            <xref linkend="svn.tour.cycle.examine.status"/>).</para>
+
+          <para>Часто новые пользователи даже не подозревают о том,
+            что их рабочая копия содержит смешаные правки. Это может
+            сбить с толку, так как многие комманды клиента чувствительны
+            к рабочей правке элемента, с которым он работает. Например,
+            команда <command>svn log</command> используется для вывода
+            истории изменения файла или директории (см. <xref
+            linkend="svn.tour.history.log"/>). Когда пользователь
+            вызывает эту команду применительно к объекту рабочей копии,
+            он ожидает увидеть полную историю этого объекта. Однако
+            если рабочая правка объекта очень старая (из-за того, что
+            команда <command>svn update</command> долго не выполнялась)
+            будет показана история для <emphasis>более старой</emphasis>
+            версии компонента рабочей копии.</para>
+
         </sect3>
 
         <sect3 id="svn.basic.in-action.mixedrevs.useful">
+          <!-- @ENGLISH {{{
           <title>Mixed revisions are useful</title>
 
           <para>If your project is sufficiently complex, you'll
@@ -1437,10 +1468,25 @@
             machine</quote> aspect of a version control system —
             the feature which allows you to move any portion of your
             working copy forward and backward in history.</para>
+          @ENGLISH }}} -->
+          <title>Смешивание правок это выгодно</title>
+
+          <para>Если у вас очень большой проект, вы можети найти
+            полезным, время от времени принудительно
+            <quote>возвращать</quote> части рабочей копии к более
+            ранним правкам; как это делается вы узнаете в Главе 3.
+            Возможно вы захотите протестировать более раннюю версию
+            модуля, находящегося в поддиректории или возможно
+            выяснить, в какой момент в конкретном файле появилась
+            ошибка. Это сущность <quote>машины времени</quote>
+            системы управления версиями — возможность которая
+            позволяет перемещать в истории любую часть рабочей копии
+            вперед и назад.</para>
 
         </sect3>
 
         <sect3 id="svn.basic.in-action.mixedrevs.limits">
+          <!-- @ENGLISH {{{
           <title>Mixed revisions have limitations</title>
 
           <para>However you make use of mixed revisions in your
@@ -1462,6 +1508,26 @@
             entries and properties, and thus committing a property
             change to an out-of-date directory may destroy properties
             you've not yet seen.</para>
+          @ENGLISH }}} -->
+          <title>Смешивание правок имеет ограничения</title>
+
+          <para>Несмотря на то, что в рабочей копии можно использовать
+            смешивание правок, в такого рода гибкости существуют
+            ограничения.</para>
+
+          <para>Во-первых, нельзя зафиксировать уделение устаревшего
+            файла или директории. Если в хранилище существует более новая
+            версия элемента, попытка удаления будет отклонена, для
+            предотвращения возможности непреднамеренного уничтожения
+            еще не виденных изменений.</para>
+
+          <para>Во-вторых, нельзя зафиксировать изменененные метаданные
+            для директории которая не полность обновлена. О присоединении
+            <quote>свойств</quote> к элементам вы узнаете в Главе 6.
+            Рабочая правка директории определяет конкретный набор входящих
+            в нее элементов и свойств, по-этому фиксация изменений свойств
+            для директории которая устарела может привести к уничтожению
+            еще не виденных свойств.</para>
 
         </sect3>
 

Modified: trunk/src/ru/book/ch03.xml
==============================================================================
--- trunk/src/ru/book/ch03.xml	(original)
+++ trunk/src/ru/book/ch03.xml	Sat Aug 13 01:09:54 2005
@@ -2151,7 +2151,7 @@
       <!-- @ENGLISH {{{
       <title>Resolve Conflicts (Merging Others' Changes)</title>
       @ENGLISH }}} -->
-      <title>Решение конфликтов (при сливании чужих изменений)</title>
+      <title>Решение конфликтов (при объединении с чужими изменениями)</title>
 
       <!-- @ENGLISH {{{
       <para>We've already seen how <command>svn status -u</command>

Modified: trunk/src/ru/book/ch04.xml
==============================================================================
--- trunk/src/ru/book/ch04.xml	(original)
+++ trunk/src/ru/book/ch04.xml	Sat Aug 13 01:09:54 2005
@@ -1310,6 +1310,7 @@
 $ svn merge -r 100:200 http://svn.example.com/repos/trunk
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>The first syntax lays out all three arguments explictly,
         naming each tree in the form <emphasis>URL at REV</emphasis> and
         naming the working copy target.  The second syntax can be used
@@ -1317,12 +1318,21 @@
         different revisions of the same URL.  The last syntax shows
         how the working-copy argument is optional; if omitted, it
         defaults to the current directory.</para>
-
+      @ENGLISH }}} -->
+      <para>В первом примере записи все три аргумента явно указаны,
+        указываются деревья, в форме <emphasis>URL at REV</emphasis> и
+        указывается целевая рабочая копия. Второй пример записи может
+        использоваться для краткости записи, в ситуациях, когда
+        сравниваются две разных правки по одному и тому же URL.
+        Последний пример демонстрирует возможность не указывать целевую
+        рабочую копию, при этом по умолчанию используется текущая
+        директория.</para>
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.copychanges.bestprac">
+      <!-- @ENGLISH {{{
       <title>Best Practices for Merging</title>
 
       <sect3 id="svn.branchmerge.copychanges.bestprac.track">
@@ -1337,7 +1347,24 @@
           typically notices if the file already has the change, and
           does nothing.  But if the already-existing change has been
           modified in any way, you'll get a conflict.</para>
+        @ENGLISH }}} -->
+      <title>Как правильнее всего использовать слияние</title>
+
+      <sect3 id="svn.branchmerge.copychanges.bestprac.track">
+        <title>Ручной контроль слияния</title>
+
+        <para>На первый взгляд объединить изменения просто, однако
+          на практике могут возникнуть трудности. Проблема заключается
+          в том, что при многократном объединении изменений одной
+          ветки с другой можно непреднамеренно сделать объединение одних
+          и тех же изменений <emphasis>дважды</emphasis>. Иногда,
+          когда это случается, проблем это не вызывает. При внемсении
+          изменений в файл, как правило Subversion предупреждает
+          о том что файл уже содержит изменения и в этом случае не
+          выполняет никаких действий. Однако если уже присутствующие
+          изменения были модифицированы, то возникнет конфликт.</para>
 
+        <!-- @ENGLISH {{{
         <para>Ideally, your version control system should prevent the
           double-application of changes to a branch.  It should
           automatically remember which changes a branch has already
@@ -1351,7 +1378,22 @@
           repository has no idea whether those changes came from
           running <command>svn merge</command>, or from just
           hand-editing the files.</para>
+        @ENGLISH }}} -->
+        <para>В идеале, система управления версиями должна предотвращать
+          повторное применение изменений к ветке. Она должна автоматически
+          фиксировать, какие изменения уже были получены и иметь возможность
+          перечислить их вам. Должна использовать эту информацию для того,
+          что бы, на сколько возможно, помочь автоматизировать
+          слияние.</para>
+
+        <para>К сожалению, Subversion не такая система. Как и
+          CVS, Subversion пока не сохраняет ни какой информации об
+          операциях объединения. При фиксации локальных изменений хранилище
+          понятия не имеет, являются ли эти изменения результатом
+          выполнения команды <command>svn merge</command> или результатом
+          обычного ручного редактирования файлов.</para>
 
+        <!-- @ENGLISH {{{
         <para>What does this mean to you, the user?  It means that
           until the day Subversion grows this feature, you'll have to
           track merge information yourself.  The best place to do this
@@ -1367,10 +1409,27 @@
 
         <para>In the next section, we'll show some examples of this
           technique in action.</para>
+        @ENGLISH }}} -->
+        <para>Что это означает для вас, как пользователя? Это означаяет,
+          что до того момента, пока у Subversion не появится этой функции,
+          вам придется контролировать слияние информации самостоятельно.
+          Лучшим местом для этого является лог-сообщение. Как было
+          показано в предыдущих примерах, рекомендуется, что бы в
+          лог-сообщении был указан конкретный номер правки (или диапазон
+          правок) которые были слиты в вашу ветку. После этого, для того,
+          что бы просмотреть какие изменения ваша ветка уже содержит,
+          вы можете запустить команду <command>svn log</command>. Это
+          позволит быть аккуратнее при выполнении команды <command>svn
+          merge</command>, что бы не пересечься с уже портированными
+          изменениями.</para>
+
+        <para>В следующем разделе мы на примерах рассмотрим эту технику
+          в действии.</para>
 
       </sect3>
 
       <sect3 id="svn.branchmerge.copychanges.bestprac.preview">
+        <!-- @ENGLISH {{{
         <title>Previewing Merges</title>
 
         <para>Because merging only results in local modifications,
@@ -1383,15 +1442,38 @@
           merge will be mixed with your pre-existing ones, and running
           <command>svn revert</command> is no longer an option.  The
           two sets of changes may be impossible to separate.</para>
+        @ENGLISH }}} -->
+        <title>Предварительные просмотр при объединении</title>
+
+        <para>Учитывая, что результатом слияния являются локальные
+          модификации, такая операция не является опасной. Если
+          в начале, при выполнении объединения вы ошиблись, просто
+          отмените изменения (<command>svn revert</command>) и
+          попробуйте еще раз.</para>
+
+        <para>Однако, возможна ситуация, когда рабочая копия уже
+          содержит локальные изменения. Изменения, примененные при
+          слиянии будут смешаны с уже существующими и
+          <command>svn revert</command> запустить будет нельзя.
+          Если нельзя будет разделить два набора изменений.</para>
 
+        <!-- @ENGLISH {{{
         <para>In cases like this, people take comfort in being able to
           predict or examine merges before they happen.  One simple
           way to do that is to run <command>svn diff</command> with
           the same arguments you plan to pass to <command>svn
           merge</command>, as we already showed in our first example
           of merging.  Another method of previewing is to pass the
-          <option>--dry-run</option> option to the merge
+          <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>
 
         <screen>
 $ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
@@ -1401,17 +1483,27 @@
 #  nothing printed, working copy is still unchanged.
 </screen>
 
-        <para>The <option>--dry-run</option> option doesn't actually
+        <!-- @ENGLISH {{{
+             <para>The <option>-ﳢ-dry-run</option> option doesn't actually
           apply any local changes to the working copy.  It only shows
           status codes that <emphasis>would</emphasis> be printed in a
           real merge.  It's useful for getting a <quote>high
           level</quote> preview of the potential merge, for those
           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>
 
       </sect3>
 
       <sidebar>
+        <!-- @ENGLISH {{{
         <title>Subversion and Changesets</title>
 
         <para>Everyone seems to have a slightly different definition
@@ -1423,7 +1515,21 @@
           to file contents, modifications to tree structure, or tweaks
           to metadata.  In more common speak, a changeset is just a
           patch with a name you can refer to.</para>
+        @ENGLISH }}} -->
+        <title>Subversion и наборы изменений</title>
+
+        <para>У каждого найдется свое, немного отличающееся
+          определение <quote>набора изменений</quote>, или во всяком
+          случая того, что это должно означать применительно к системе
+          управления версиями с <quote>поддерживающей наборы
+          изменений</quote>. Для нашего случая будем считать, что
+          набор изменений это просто модификации объединенные под
+          уникальным именем. Изменения могут заключаться в редактировании
+          текста файлов, модификации структуры файлов или корректировке
+          метаданных. Проще говоря, набор изменений это просто патч
+          с заданным для него именем.</para>
 
+        <!-- @ENGLISH {{{
         <para>In Subversion, a global revision number N names a tree
           in the repository: it's the way the repository looked after
           the Nth commit.  It's also the name of an implicit
@@ -1442,9 +1548,32 @@
           to another by naming them in the merge arguments:
           <command>svn merge -r9237:9238</command> would merge
           changeset #9238 into your working copy.</para>
+        @ENGLISH }}} -->
+        <para>В Subversion глобальный номер правки N относится к
+          дереву в хранилище: так выглядит хранилище после
+          фиксации N. Кроме того, это имя для неявного набора
+          изменений: если сравнить дерево N с деревом N-1 вы получите
+          полный патч того, что было зафиксировано. В этом смысле,
+          о <quote>правке N</quote> можно думать не как о дереве
+          файлов, а как о наборе изменений. Если вы пользуетесь
+          системой отслеживания релизов для управления ошибоками,
+          вы можете использовать номера правок для того, что бы
+          ссылаться на конкретные патчи, которые исправляют
+          ошибку — например, <quote>этот релиз был исправлен
+          правкой 9238.</quote>. После этого, для того, что бы прочитать
+          о том наборе изменений, который исправляет ошибку можно выполнить
+          <command>svn log -r9238</command>, а для того, что бы увидеть
+          сам патч, выполнить <command>svn diff -r9237:9238</command>.
+          В Subversion команда для объединения то-же использует
+          номера правок. Можно объединить набор изменений из одной ветки
+          в другую указав его в качестве аргумента:
+          команда <command>svn merge -r9237:9238</command> внедрит
+          набор изменений #9238 в вашу рабочую копию.</para>
+
       </sidebar>
 
       <sect3 id="svn.branchmerge.copychanges.bestprac.merge">
+        <!-- @ENGLISH {{{
         <title>Merge Conflicts</title>
 
         <para>Just like the <command>svn update</command> command,
@@ -1464,7 +1593,28 @@
           comparison is exactly equal to what you already have, the
           delta is guaranteed to correctly convert your working copy
           into the right-hand tree.</para>
+        @ENGLISH }}} -->
+        <title>Конфликты при объединении</title>
+
+        <para>Так же как и команда <command>svn update</command>,
+          <command>svn merge</command> внедряет изменения в
+          рабочую копию. А следовательно то-же может создавать
+          конфликты. Однако конфликты, создаваемые <command>svn
+          merge</command> иногда отличаются и эти отличия
+          рассмотрены в этом разделе.</para>
+
+        <para>В начале будем считать, что рабочая копия не имеет
+          локальных изменений. При обновлении (<command>svn
+          update</command>) до конкретной правки, изменения, отправляемые
+          сервером, будут всегда <quote>без проблем</quote> внедрятся
+          в рабочую копию. Сервер создает дельту сравнивая два дерева:
+          виртуальный снимок рабочей копии и дерево файлов, которое
+          вас интересует. Учитывая то, что левая часть сравнения
+          полностью эквивалентна тому, что вы уже имеете, дельта
+          гарантированно правильно конвертирует рабочую копию в правую
+          часть сравнения.</para>
 
+        <!-- @ENGLISH {{{
         <para>But <command>svn merge</command> has no such guarantees
           and can be much more chaotic: the user can ask the server to
           compare <emphasis>any</emphasis> two trees at all, even ones
@@ -1477,6 +1627,22 @@
           <command>patch</command> command sometimes complains about
           <quote>failed hunks</quote>, <command>svn merge</command>
           will complain about <quote>skipped targets</quote>:</para>
+        @ENGLISH }}} -->
+        <para>Однако <command>svn merge</command> не может этого
+          гарантировать и и может вести себя более хаотично:
+          пользователь может запросить сервер сравнить
+          <emphasis>любые</emphasis> два дерева файлов, даже такие,
+          которые не имеют отношения к рабочей копии! Из этого
+          следует большое количество потенциальных человеческих
+          ошибок. Пользователи иногда будут сравнивать два
+          ошибочных дерева создавая дельту которая не
+          сможет правильно внедриться. <command>svn
+          merge</command> будет пытаться внедрить по возможности
+          больше различий, но иногда это будет не возможно.
+          Так же как команда <command>patch</command> в Unix
+          иногда жалуется на <quote>неудачные попытки</quote>
+          объединения, <command>svn merge</command> будет
+          жаловаться на <quote>пропущеные цели</quote>:</para>
 
 <screen>
 $ svn merge -r 1288:1351 http://svn.example.com/repos/branch
@@ -1489,6 +1655,7 @@
 $
 </screen>
 
+        <!-- @ENGLISH {{{
         <para>In the previous example it might be the case that
           <filename>baz.c</filename> exists in both snapshots of the
           branch being compared, and the resulting delta wants to
@@ -1498,7 +1665,7 @@
           likely comparing the wrong two trees; they're the classic
           sign of driver error.  When this happens, it's easy to
           recursively revert all the changes created by the merge
-          (<command>svn revert --recursive</command>), delete any
+          (<command>svn revert -ﳢ-recursive</command>), delete any
           unversioned files or directories left behind after the
           revert, and re-run <command>svn merge</command> with
           different arguments.</para>
@@ -1511,7 +1678,33 @@
           delta to the working copy, that delta may contain textual
           changes that don't cleanly apply to a working file, even if
           the file has no local modifications.</para>
+        @ENGLISH }}} -->
+        <para>Возможно, что в предыдущем примере файл
+          <filename>baz.c</filename> существует в обоих сравниваемых
+          снимках ветки и Subversion пытается применить результирующую
+          дельту для того, чтобы изменить содержимое файла, однако в
+          рабочей копии файл отсутствует. В любом случае сообщение
+          <quote>skipped</quote> означает, что скорее всего пользователь
+          ошибся при указании деревьев для сравнения; классическая ошибка
+          оператора. Если это произошло, то проще всего рекурсивно
+          отменить все изменения, сделанные при слиянии (<command>svn
+          revert --recursive</command>), сразу же после этого удалить
+          все не версионированные файлы и директории и повторно
+          запустить <command>svn merge</command> с другими
+          параметрами.</para>
+
+        <para>Обратите внимание на то, что в предыдущем примере
+          в файле <filename>glorb.h</filename> возник конфликт.
+          Ранее мы договорились, что рабочая копия не имеет
+          локальных изменений: откуда же взялся конфликт?
+          Опять же, так как пользователь мог запустить <command>svn
+          merge</command> для выделения и применения к рабочей копии
+          какой то старой дельты, в результате, такая дельта может
+          содержать изменения, которые не смогут внедриться в рабочий
+          файл без появления проблем, даже если он не имеет локальных
+          изменений.</para>
 
+        <!-- @ENGLISH {{{
         <para>Another small difference between <command>svn
           update</command> and <command>svn merge</command> are the
           names of the full-text files created when a conflict
@@ -1530,10 +1723,30 @@
           distinguish between conflicts that happened as a result of an
           update versus ones that happened as a result of a
           merge.</para>
+        @ENGLISH }}} -->
+        <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.rNEWREV</filename>. А <command>svn
+          merge</command> в конфликтной ситуации созает три файла
+          с названиями <filename>filename.working</filename>,
+          <filename>filename.left</filename> и
+          <filename>filename.right</filename>. Здесь, термины
+          <quote>left</quote> и <quote>right</quote> указывают
+          на две стороны сравнения, то есть на используемые при
+          сравнении деревьевья. Это разделение используемых названий
+          поможет вам отличать конфликты возникшие в результате
+          обновления от конфликтов, возникших возникших в результате
+          объединения.</para>
 
       </sect3>
 
       <sect3 id="svn.branchmerge.copychanges.bestprac.ancestry">
+        <!-- @ENGLISH {{{
         <title>Noticing or Ignoring Ancestry</title>
 
         <para>When conversing with a Subversion developer, you might
@@ -1555,7 +1768,30 @@
           (they have the same path), but in fact are completely
           different objects in the repository.  They share no history
           or <quote>ancestry</quote>.</para>
+        @ENGLISH }}} -->
+        <title>Учитывать или игнорировать происхождение</title>
+
+        <para>При общении разработчиков, использующих Subversion
+          очень часто можно услышать упоминание термина
+          <firstterm>происхождение</firstterm>. Это слово используется
+          для описания отнешений между двумя объектами хранилища:
+          если между ними есть связь, тогда говорят, что один объект
+          является предком другого.</para>
+
+        <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>
+          могут выглядеть так, как будто они имеют друг к другу отношение
+          (у них одинаковый путь), однако на самом деле являются
+          полностью независимымы объектами хранилища. Они не имеют
+          ни общей истории ни общих <quote>предков</quote>.</para>
 
+        <!-- @ENGLISH {{{
         <para>The reason for bringing this up is to point out an
           important difference between <command>svn diff</command> and
           <command>svn merge</command>.  The former command ignores
@@ -1569,7 +1805,22 @@
           the old file, then add the new file;  you would see a
           <literal>D  foo.c</literal> followed by a <literal>A
           foo.c</literal>.</para>
+        @ENGLISH }}} -->
+        <para>Мы обращаем на это ваше внимание, для того, чтобы
+          указать на важные отличия между <command>svn diff</command>
+          и <command>svn merge</command>. Первая команда игнорирует
+          происхождение, в то время, как вторая его учитывает.
+          Например, если попросить <command>svn diff</command> сравнить
+          правки 99 и 102 файла <filename>foo.c</filename> вы увидите
+          построчное сравнение; команда сравнения слепо сравнивает
+          два пути. А вот если вы попросите <command>svn merge</command>
+          сравнить те-же объекты, то Subversion предупредит вас о том, что
+          они не связаны друг с другом и сначала попытается удалить
+          старый файл, а затем добавить новый; сначала вы увидите
+          <literal>D  foo.c</literal>, а затем <literal>A
+          foo.c</literal>.</para>
 
+        <!-- @ENGLISH {{{
         <para>Most merges involve comparing trees that are ancestrally
           related to one another, and therefore <command>svn
           merge</command> defaults to this behavior.  Occasionally,
@@ -1584,12 +1835,34 @@
         <para>In these situations, you'll want <command>svn
           merge</command> to do a path-based comparison only, ignoring
           any relations between files and directories.  Add the
-          <option>--ignore-ancestry</option> option to your merge
+          <option>-ﳢ-ignore-ancestry</option> option to your merge
           command, and it will behave just like <command>svn
           diff</command>.  (And conversely, the
-          <option>--notice-ancestry</option> option will cause
+          <option>-ﳢ-notice-ancestry</option> option will cause
           <command>svn diff</command> to behave like the merge
           command.)</para>
+        @ENGLISH }}} -->
+        <para>В большинстве случаев при объединении сравниваются
+          деревья, имеющие родственную связь и по умолчанию
+          <command>svn merge</command> расчитывает на это. Однако
+          иногда, вам будет нужно, что бы команда объединения сравнила
+          два не связанных дерева файлов. Например, у вас может быть
+          два импортированных дерева содержащих исходный код
+          релизов програмных проектов от сторонних поставщиков
+          (см. <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>
 
       </sect3>
 
@@ -1602,14 +1875,22 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.commonuses">
+    <!-- @ENGLISH {{{
     <title>Common Use-Cases</title>
 
     <para>There are many different uses for branching and <command>svn
       merge</command>, and this section describes the most common ones
       you're likely to run into.</para>
+    @ENGLISH }}} -->
+    <title>Типовые примеры использования</title>
+
+    <para>Для ветвления и команды <command>svn merge</command>
+      существует множество применений, в этом раздели описаны наиболее
+      типичные из тех с которыми вы можете столкнуться.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.commonuses.wholebr">
+      <!-- @ENGLISH {{{
       <title>Merging a Whole Branch to Another</title>
 
       <para>To complete our running example, we'll move forward in
@@ -1627,6 +1908,16 @@
         assume that either you still have your original one lying
         around (fully updated), or that you recently checked out a
         fresh working copy of <filename>/calc/trunk</filename>.</para>
+      @ENGLISH }}} -->
+      <title>Полное объединение двух веток</title>
+
+      <para>Что бы завершить наш текущий пример, заглянем немного
+        в перед. Предположим, прошло несколько дней и как в главную
+        линию разработки так и вашу личную ветку было внесено множество
+        изменений. Допустим, что работу над своей веткой вы завершили;
+        добавление функциональности или исправление ошибок наконец
+        законено и теперь вы хотите объединить все изменения из своей
+        ветки с главной линией разработки.</para>
 
       <para>But which two trees should be compared?  At first glance,
         the answer may seem obvious: just compare the latest trunk

Modified: trunk/src/ru/sync.py
==============================================================================
--- trunk/src/ru/sync.py	(original)
+++ trunk/src/ru/sync.py	Sat Aug 13 01:09:54 2005
@@ -11,7 +11,7 @@
   stream = err_msg and sys.stderr or sys.stdout
   if err_msg:
     stream.write("ERROR: %s\n\n" % (err_msg))
-  stream.write("""Usage: %s [-f <filename>] [-lv]
+  stream.write("""Usage: %s [-f <filename>] [-l]
 
 Options:
     -f:    File which needs to be synchronized
@@ -65,6 +65,7 @@
   return "(%3.2f%%)" % ((ru / en) * 100)
 
 def get_list():
+  import platform
   global bfiles
   frlist = ()
   rmin = 0xffffffff
@@ -77,12 +78,15 @@
   rdelta1 = rmin + ((rbase - rmin) / 3)
   rdelta2 = rbase - ((rbase - rmin) / 3)
   for f, r in frlist:
-    if r in range(rdelta2, rbase):
-      print '\x1b[32m', f, '\t', r, '\t', get_status(f), '\x1b[0m'
-    elif r in range(rdelta1, rdelta2):
-      print '\x1b[33m', f, '\t', r, '\t', get_status(f), '\x1b[0m'
-    elif r in range(rmin, rdelta1):
-      print '\x1b[31m', f, '\t', r, '\t', get_status(f), '\x1b[0m'
+    if platform.system() == 'Windows':
+      print f, '\t', r, '\t', get_status(f)
+    else:
+      if r in range(rdelta2, rbase):
+        print '\x1b[32m', f, '\t', r, '\t', get_status(f), '\x1b[0m'
+      elif r in range(rdelta1, rdelta2):
+        print '\x1b[33m', f, '\t', r, '\t', get_status(f), '\x1b[0m'
+      elif r in range(rmin, rdelta1):
+        print '\x1b[31m', f, '\t', r, '\t', get_status(f), '\x1b[0m'
 
 def main():
   global bfiles



More information about the svnbook-dev mailing list