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

dmitriy svnbook-dev at red-bean.com
Wed Aug 24 03:07:23 CDT 2005


Author: dmitriy
Date: Wed Aug 24 03:07:22 2005
New Revision: 1638

Modified:
   trunk/src/ru/book/ch04.xml
Log:
* ru/book/ch04.xml
  Translated the following parts of 'svn.branchmerge.commonuses':
  - wholebr,
  - undo,
  - resurrect


Modified: trunk/src/ru/book/ch04.xml
==============================================================================
--- trunk/src/ru/book/ch04.xml	(original)
+++ trunk/src/ru/book/ch04.xml	Wed Aug 24 03:07:22 2005
@@ -2249,6 +2249,7 @@
          изменений больше не будет отражен в правке
          <literal>HEAD</literal>.</para>
 
+      <!-- @ENGLISH {{{
       <para>Again, you may be thinking: well, that really didn't undo
         the commit, did it?  The change still exists in revision 303.
         If somebody checks out a version of the
@@ -2279,10 +2280,38 @@
             workaround.</para>
         </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>
+        с помощью которой можно будет выборочно удалять информацию.
+        А пока за возможным решением проблемы обратитесь к разделу <xref
+        linkend="svn.reposadmin.maint.tk.svndumpfilter"/>.</para>
+        </footnote></para>
 
     </sect2>
 
     <!-- =============================================================== -->
+    <!-- @ENGLISH {{{
     <sect2 id="svn.branchmerge.commonuses.resurrect">
       <title>Resurrecting Deleted Items</title>
 
@@ -2301,7 +2330,28 @@
         and the second coordinate is a path within that tree.  So
         every version of your file or directory can be defined by a
         specific coordinate pair.</para>
+    @ENGLISH }}} -->
+    <sect2 id="svn.branchmerge.commonuses.resurrect">
+      <title>Востановление удаленных элементов</title>
+
+      <para>Отличным свойством системы контроля версия является то,
+        что информация никогда не теряется. При удалении файла
+        или директории, элемент исчезает из правки <literal>HEAD</literal>
+        но продолжает существовать в более ранних правках. Одним
+        из наиболее частых вопросов, задаваемых новыми пользователями,
+        является такой: <quote>Как мне вернуть назад свой файл или
+        директорию?</quote></para>
+
+      <para>Первым шагом является определение того, <emphasis
+        role="bold">какой именно</emphasis> элемент вы пытаетесь
+        востановить. Неплохой метафорой является представление
+        каждого объекта в хранилище существующим в двухмерной системе
+        координат. Первой координатой является отдельное дерево правок,
+        второй координатой является путь в этом дереве. Таким образом
+        каждая версия файла или директории может быть представлена
+        конкретной парой координат.</para>
 
+      <!-- @ENGLISH {{{
       <para>Subversion has no <filename>Attic</filename> directory
         like CVS does,
         <footnote>
@@ -2312,13 +2362,30 @@
         so you need to use <command>svn
         log</command> to discover the exact coordinate pair you wish
         to resurrect.  A good strategy is to run <command>svn log
-        --verbose</command> in a directory which used to contain your
-        deleted item.  The <option>--verbose</option> option shows a
+        -ﳢ-verbose</command> in a directory which used to contain your
+        deleted item.  The <option>-ﳢ-verbose</option> option shows a
         list of all changed items in each revision; all you need to do
         is find the revision in which you deleted the file or
         directory.  You can do this visually, or by using another tool
         to examine the log output (via <command>grep</command>, or
         perhaps via an incremental search in an editor).</para>
+      @ENGLISH }}} -->
+      <para>Subversion, в отличии от CVS, не имеет директории
+        <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>
 
       <screen>
 $ cd parent-dir
@@ -2335,6 +2402,7 @@
 …
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>In the example, we're assuming that you're looking for a
         deleted file <filename>real.c</filename>.  By looking through
         the logs of a parent directory, you've spotted that this file
@@ -2355,7 +2423,28 @@
         re-adding <filename>real.c</filename> as a local modification.
         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. Следовательно, последняя существовавшая версия файла
+        была в правке, предществующей этой. Вывод: необходимо из
+        правки 807 востанавить путь
+        <filename>/calc/trunk/real.c</filename>.</para>
+
+      <para>Поиск был сложной задачей. Теперь, когда известно, что
+        нужно востановить, есть две возможности.</para>
+
+      <para>Одним из вариантов является использование <command>svn
+        merge</command> для применения правки 808 <quote>в обратном
+        направлении</quote>. (Как отменять изменения мы уже рассматривали,
+        см. <xref linkend="svn.branchmerge.commonuses.undo"/>.) Это
+        приведет к эффекту повторного добавления фала
+        <filename>real.c</filename> в виде локальных изменений.
+        Файл будет запланирован для добавления и после фиксации
+        будет опять присутствовать в <literal>HEAD</literal>.</para>
 
+      <!-- @ENGLISH {{{
       <para>In this particular example, however, this is probably not
         the best strategy.  Reverse-applying revision 808 would not
         only schedule <filename>real.c</filename> for addition, but
@@ -2372,6 +2461,22 @@
         <command>svn copy</command> command.  Simply copy the exact
         revision and path <quote>coordinate pair</quote> from the
         repository to your working copy:</para>
+      @ENGLISH }}} -->
+      <para>Однако в этом, отдельно взятом примере, это не самое лучшее
+        решение. Повторное применение правки 808 не только добавит
+        файл <filename>real.c</filename>; лог сообщение показывает, что
+        будут отменены некоторые изменения в <filename>integer.c</filename>,
+        чего вы не хотите. Конечно, можно выполнить обратное объединение
+        с правкой 808, а затем отменить (<command>svn revert</command>)
+        локальные изменения <filename>integer.c</filename>, однако такой
+        подход плохо маштабируется. Что если в правке 808 было измененно
+        90 файлов?</para>
+
+      <para>При втором, более целевом методе, <command>svn merge</command>
+        вообще не используется, а вместо этого применяется команда
+        <command>svn copy</command>. Просто скопируете определенные
+        <quote>парой координат</quote> правку и путь из хранилища в
+        рабочую копию:</para>
 
       <screen>
 $ svn copy --revision 807 \
@@ -2386,6 +2491,7 @@
 Committed revision 1390.
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>The plus sign in the status output indicates that the item
         isn't merely scheduled for addition, but scheduled for
         addition <quote>with history</quote>. Subversion remembers
@@ -2399,6 +2505,20 @@
       <para>Although our example shows us resurrecting a file, note
         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>
 
     </sect2>
 



More information about the svnbook-dev mailing list