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

dmitriy svnbook-dev at red-bean.com
Sat Aug 27 04:52:39 CDT 2005


Author: dmitriy
Date: Sat Aug 27 04:52:36 2005
New Revision: 1645

Modified:
   trunk/src/ru/book/ch04.xml   (contents, props changed)
Log:
* ru/book/ch04.xml
  Translation work is finished, file is ready for editing


Modified: trunk/src/ru/book/ch04.xml
==============================================================================
--- trunk/src/ru/book/ch04.xml	(original)
+++ trunk/src/ru/book/ch04.xml	Sat Aug 27 04:52:36 2005
@@ -2524,6 +2524,7 @@
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.commonuses.patterns">
+      <!-- @ENGLISH {{{
       <title>Common Branching Patterns</title>
 
       <para>Version control is most often used for software
@@ -2537,8 +2538,24 @@
         Subversion; they're applicable to any version control system.
         Still, it may help to see them described in Subversion
         terms.</para>
+      @ENGLISH }}} -->
+      <title>Типовые приемы при использовании веток</title>
+
+      <para>Управление версиями чаще всего используется при
+        разработке програмного обеспечения, по-этому здесь мы
+        вкратце рассмотрим два, наиболее часто используемые командами
+        программистов, приема ветвления/слияния. Если вы не используете
+        Subversion для разработки программного обеспечения, можете
+        пропустить этот раздел. Если вы разработчик программного
+        обеспечения использующий контроль версий впервые, внимательно
+        присмотритесь, поскольку опытные разработчики считают использование
+        этих приемов хорошим стилем работы. Такие приемы не являются
+        специфичными для Subversion; они применимы к любой системе
+        управления версиями. Тем более, что это поможет увидеть
+        их описание в терминах Subversion.</para>
 
       <sect3 id="svn.branchmerge.commonuses.patterns.release">
+        <!-- @ENGLISH {{{
         <title>Release Branches</title>
 
         <para>Most software has a typical lifecycle: code, test,
@@ -2555,9 +2572,29 @@
 
         <para>Here's where version control can help.  The typical
           procedure looks like this:</para>
+        @ENGLISH }}} -->
+        <title>Ветки релизов</title>
+
+        <para>Большинство программного обеспечения имеет типовой
+          жизненый цикл: написание кода, тестирование, выпуск,
+          повторный цикл. При таком подходе возникают две проблемы.
+          Во-первых, разработчикам необходимо продолжать расширять
+          функциональность в то время, как группа проверки качества
+          будет заниматься тестированием предположительно стабильных
+          версий программы. Во время тестирования не должна останавливаться
+          разработка. Во-вторых, как правило, требуется поддерживать старые,
+          уже выпущенные версии программы; если найдена ошибка в
+          последней версии кода, то скорее всего она присутствует и в уже
+          выпущенных версиях, по-этому пользователи захотят, что-бы
+          эта ошибка была исправлена не дожидаясь выхода новой версии
+          программы.</para>
+
+        <para>Здесь-то и может помочь контроль версий. Типичная процедура
+          выглядит примерно так:</para>
 
       <itemizedlist>
 
+        <!-- @ENGLISH {{{
         <listitem>
           <para><emphasis>Developers commit all new work to the
                 trunk.</emphasis>
@@ -2576,7 +2613,27 @@
               might be copied to
               <filename>/branches/1.0</filename>.</para>
         </listitem>
+        @ENGLISH }}} -->
+        <listitem>
+          <para><emphasis>Разработчики фиксируют все новое в главную
+                линию разработки.</emphasis>
+
+              Каждодневные изменения фиксируются в
+              <filename>/trunk</filename>: новая функциональность,
+              исправление ошибок и тому подобное.</para>
+        </listitem>
+
+        <listitem>
+          <para><emphasis>Главная линия разработки копируется в ветку
+                <quote>релиза</quote>.</emphasis>
+
+              Когда команда разработчиков решает, что программа готова
+              к выпуску (скажем, к релизу 1.0), тогда
+              <filename>/trunk</filename> копируется, например, в
+              <filename>/branches/1.0</filename>.</para>
+        </listitem>
 
+        <!-- @ENGLISH {{{
         <listitem>
           <para><emphasis>Teams continue to work in parallel.</emphasis>
 
@@ -2598,7 +2655,30 @@
               snapshot.  The tag is packaged and released to
               customers.</para>
         </listitem>
+        @ENGLISH }}} -->
+        <listitem>
+          <para><emphasis>Группы продолжают работать паралельно.</emphasis>
+
+              Одна группа начинает всестороннее тестирование ветки релиза,
+              в то время как вторая группа продолжает работу (скажем, над
+              версией 2.0) в <filename>/trunk</filename>. Если находятся
+              ошибки в какой-либо из версий, исправления портируются по
+              необходимости в одну или другую сторону. В какой-то момент этот
+              процесс останавливается. Ветка <quote>замораживается</quote>
+              для окончательной проверки перед релизом.</para>
+        </listitem>
+
+        <listitem>
+          <para><emphasis>На основе ветки создается метка и выпускается
+            релиз.</emphasis>
 
+              Когда тестирование завершено,
+              <filename>/branches/1.0</filename> копируется в
+              <filename>/tags/1.0.0</filename> как справочный снимок.
+              Метка запаковывается и отправляется пользователям.</para>
+        </listitem>
+
+        <!-- @ENGLISH {{{
         <listitem>
           <para><emphasis>The branch is maintained over time.</emphasis>
 
@@ -2611,19 +2691,42 @@
               copied to <filename>/tags/1.0.1</filename>, and the tag
               is packaged and released.</para>
         </listitem>
+        @ENGLISH }}} -->
+        <listitem>
+          <para><emphasis>Ветка продолжает поддерживаться</emphasis>
+
+              По мере продвижения работы над <filename>/trunk</filename>
+              для версии 2.0, исправления ошибок продолжают портироваться
+              из <filename>/trunk</filename> в
+              <filename>/branches/1.0</filename>. Когда будет накоплено
+              определенной количество исправлений, руководство может решить
+              сделать релиз 1.0.1: <filename>/branches/1.0</filename>
+              копируется  в <filename>/tags/1.0.1</filename>, метка
+              пакуется и выпускается.</para>
+        </listitem>
 
         </itemizedlist>
 
+        <!-- @ENGLISH {{{
         <para>This entire process repeats as the software matures:
           when the 2.0 work is complete, a new 2.0 release branch is
           created, tested, tagged, and eventually released.  After
           some years, the repository ends up with a number of release
           branches in <quote>maintenance</quote> mode, and a number
           of tags representing final shipped versions.</para>
+        @ENGLISH }}} -->
+        <para>По мере развития программы эти этапы повторяются:
+          когда работа над 2.0 будет завершена, создается новая ветка
+          релиза 2.0, тестируется, создается метка и в последствии
+          выпускается релиз. После нескольких лет в хранилище будет
+          находиться определенное количество веток релизов, находящихся
+          в режиме <quote>сопровождения</quote> и определенное количество
+          меток, отражающих последние выпущенные ветки.</para>
 
       </sect3>
 
       <sect3 id="svn.branchmerge.commonuses.patterns.feature">
+        <!-- @ENGLISH {{{
         <title>Feature Branches</title>
 
         <para>A <firstterm>feature branch</firstterm> is the sort of
@@ -2651,7 +2754,37 @@
           the branch is deleted.  This system guarantees an
           exceptionally stable and usable trunk at all times, but at
           the cost of tremendous process overhead.</para>
+        @ENGLISH }}} -->
+        <title>Функциональные ветки</title>
 
+        <para><firstterm>Функциональная ветка</firstterm> является
+          доминирующим примером в этой главе, над такой веткой вы работаете
+          пока Салли работает над <filename>/trunk</filename>. Это временная
+          ветка, которая создается для работы над комплексным изменением
+          без пересечения со стабильной линией разработки
+          <filename>/trunk</filename>. В отличие от веток релизов
+          (которые могут поддерживаться вечно), функциональные ветки
+          создаются, используются, внедряются обратно в главную линию
+          разработки, после чего полностью удаляются. Они имеют ограниченый
+          срок использования.</para>
+
+        <para>Опять же, правила проекта относительно определения момента,
+          когда требуется создание функциональной ветки могут быть разными.
+          Некоторые проекты вообще никогда не используют функциональные ветки:
+          все фиксируется в <filename>/trunk</filename>. Преимущества такой
+          системы в ее простоте — никому не нужно учиться делать
+          ветки или объединения. Недостатком является то, что главная линия
+          разработки часто не стабильна или не пригодна к использованию.
+          В других проектах ветки используют по-другому:
+          <emphasis>ни одного</emphasis> изменения не фиксируют в главной
+          линии разработки напрямую. Даже для самых простых изменений
+          создается краткосрочная ветка, внимательно анализируется и
+          объединяется с главной линией. После чего ветка удаляется. Ценой
+          огромных накладных расходов, такая система гарантирует
+          исключительную стабильность и пригодность к использованию главной
+          линии разработки в любой момент времени.</para>
+
+        <!-- @ENGLISH {{{
         <para>Most projects take a middle-of-the-road approach.  They
           commonly insist that <filename>/trunk</filename> compile and
           pass regression tests at all times.  A feature branch is
@@ -2673,7 +2806,30 @@
           may continue to pour in, to the point where the two lines of
           development differ so greatly that it may become a nightmare
           trying to merge the branch back to the trunk.</para>
+        @ENGLISH }}} -->
+        <para>Большинство проектов использует что-то среднее. Как правило,
+          все время контролируя, что <filename>/trunk</filename>
+          компилируется и проходит регрессивные тесты. Функциональная ветка
+          требуется только тогда, когда изменение требует большого количества
+          дестабилизирующих фиксаций. Хорошим способом проверки является
+          постановка такого вопроса: если разработчик работал несколько
+          дней изолировано, а затем за один раз зафиксировавал большое
+          изменение (при том, что <filename>/trunk</filename> не будет
+          дестабилизирован) будет ли сложно отследить это изменение? Если
+          ответ на этот вопрос <quote>да</quote>, то тогда изменение должно
+          разрабатываться в функциональной ветке. По мере того, как
+          разработчик последовательно фиксирует изменения в ветку, они могут
+          легко отслеживаться другими участниками.</para>
+
+        <para>Напоследок, рекомендация, как по ходу работы лучше всего
+          сохранять функциональную ветку <quote>синхронизированой</quote> с
+          главной линией разработки. Как мы уже говорили, рисковано работать
+          над веткой в течении недель или месяцев; изменения в главной линии
+          будут продолжаться, и настанет момента, когда две линии разработки
+          станут отличаться так сильно, что  попытка объединить ветку обратно
+          с главной линией разработки может стать ночным кошмаром.</para>
 
+        <!-- @ENGLISH {{{
         <para>This situation is best avoided by regularly merging
           trunk changes to the branch.  Make up a policy: once a week,
           merge the last week's worth of trunk changes to the branch.
@@ -2694,6 +2850,28 @@
           identical except for your branch changes.  So in this
           special case, you would merge by comparing the branch with
           the trunk:</para>
+        @ENGLISH }}} -->
+        <para>Этой ситуации не возникнет, если регулярно объединять ветку с
+          изменениями в главной линии. Возьмите за правило один раз в неделю
+          объединять с веткой значимые изменения в главной линии разработки за
+          прошедшую неделю. Делайте это аккуратно; за объединением необходим
+          ручной контроль для того, что бы исключить проблему повторных
+          объединений (как это описано в разделе <xref
+          linkend="svn.branchmerge.copychanges.bestprac.track"/>). Необходимо
+          внимательно записывать лог сообщение, указывая какой именно
+          диапазон правок был объединен (как показано в разделе <xref
+          linkend="svn.branchmerge.commonuses.wholebr"/>). Возможно это
+          звучит устрашающе, но на самом деле это сделать очень
+          легко.</para>
+
+        <para>Начиная с какого-то момента вы будете готовы объединить
+          <quote>синхронизированную</quote> функциональную ветку с главной
+          линией разработки. Для этого начните с завершающего объединения
+          последних изменений из главной линии разработки с веткой. После
+          чего, последняя версия ветки и главной линии будут абсолютно
+          идентичны, за исключением ваших изменений в ветке. Теперь
+          объединение заключается в сравнении ветки с главной линией
+          разработки:</para>
 
         <screen>
 $ cd trunk-working-copy
@@ -2710,6 +2888,7 @@
 …
 </screen>
 
+        <!-- @ENGLISH {{{
         <para>By comparing the <literal>HEAD</literal> revision of the
           trunk with the <literal>HEAD</literal> revision of the
           branch, you're defining a delta that describes only the
@@ -2724,6 +2903,21 @@
           <emphasis>is</emphasis> a working copy but a very shallow
           private branch?  It's a branch that's only capable of
           storing one change at a time.</para>
+        @ENGLISH }}} -->
+        <para>Сравнивая правку <literal>HEAD</literal> главной линии
+          разработки и правку <literal>HEAD</literal> ветки, определяется
+          дельта, которая представляет собой только изменения сделанные в
+          ветке; обе линии разработки уже содержат все изменения из
+          главной линии.</para>
+
+        <para>Другим способом представления этого приема является то, что
+          еженедельная синхронизация ветки аналогична запуску <command>svn
+          update</command> в рабочей копии, в то время как окончательное
+          объединение аналогично запуску из рабочей копии <command>svn
+          commit</command>. В конце концов, <emphasis>что же
+          такое</emphasis> рабочая копия если не миниатюрная личная ветка?
+          Эта такая ветка которая способна хранить одно изменение
+          в каждый момент времени.</para>
 
       </sect3>
 
@@ -2735,6 +2929,7 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.switchwc">
+    <!-- @ENGLISH {{{
     <title>Switching a Working Copy</title>
 
     <para>The <command>svn switch</command> command transforms an
@@ -2746,6 +2941,18 @@
       simply ask Subversion to change your working copy of
       <filename>/calc/trunk</filename> to mirror the new branch
       location:</para>
+    @ENGLISH }}} -->
+    <title>Переключение рабочей копии</title>
+
+    <para>Команда <command>svn switch</command> трансформирует
+      существующую рабочую копию в другую ветку. Несмотря на то, что
+      при работе с ветками эта команда не является крайне необходимой,
+      она значительно облегчает жизнь пользователям. В ранее приведенном
+      примере, после создания личной ветки вы создавали новую рабочую
+      копию созданой директории хранилища. Вместо этого, можно
+      попросить Subversion изменить рабочую копию
+      <filename>/calc/trunk</filename> так, что бы она отражала
+      созданую ветку:</para>
 
 <screen>
 $ cd calc
@@ -2763,6 +2970,7 @@
 URL: http://svn.example.com/repos/calc/branches/my-calc-branch
 </screen>
 
+    <!-- @ENGLISH {{{
     <para>After <quote>switching</quote> to the branch, your working
       copy is no different than what you would get from doing a fresh
       checkout of the directory.  And it's usually more efficient to
@@ -2772,7 +2980,7 @@
       directory.</para>
 
     <para>The <command>svn switch</command> command also takes a
-      <option>--revision</option> (<option>-r</option>) option, so you
+      <option>-ﳢ-revision</option> (<option>-r</option>) option, so you
       need not always move your working copy to the <quote>tip</quote>
       of the branch.</para>
 
@@ -2780,7 +2988,26 @@
       <filename>calc</filename> example, containing multiple
       subdirectories.  Subversion users often follow a specific
       algorithm when using branches:</para>
+    @ENGLISH }}} -->
+    <para>После <quote>переключения</quote> на ветку, рабочая копия
+      не будет отличаться от той которая получилась бы при созданании
+      новой рабочей копии директории хранилища. Как правило, более
+      эффективно использовать эту команду, так как обычно у ветки
+      немного отличий. Сервер отправляет минимально необходимый для
+      того, что бы рабочая копия отражала директорию ветки, набор
+      изменений.</para>
+
+    <para>Команда <command>svn switch</command> принимает параметр
+      <option>--revision</option> (<option>-r</option>), по-этому
+      необязательно помещать рабочую копию на самую
+      <quote>верхущку</quote> ветки.</para>
+
+    <para>Конечно, большинство проектов, по сравнению с нашим примером
+      <filename>calc</filename> более сложны, содержат множество
+      поддиректорий. Обычно пользователи Subversion использут
+      специальный алгоритм для работы с ветками:</para>
 
+      <!-- @ENGLISH {{{
       <orderedlist>
         <listitem>
           <para>Copy the project's entire <quote>trunk</quote> to a
@@ -2791,7 +3018,19 @@
             working copy to mirror the branch.</para>
         </listitem>
       </orderedlist>
+      @ENGLISH }}} -->
+      <orderedlist>
+        <listitem>
+          <para>Скопировать всю директорию <quote>trunk</quote> в
+            директорию новой ветки.</para>
+        </listitem>
+        <listitem>
+          <para>Переключить <emphasis>часть</emphasis> главной линии
+            разработки на ветку.</para>
+        </listitem>
+      </orderedlist>
 
+    <!-- @ENGLISH {{{
     <para>In other words, if a user knows that the branch-work only
       needs to happen on a specific subdirectory, they use
       <command>svn switch</command> to move only that subdirectory to
@@ -2810,7 +3049,28 @@
       normal.  When you update, you'll receive patches to each subtree
       as appropriate.  When you commit, your local changes will still
       be applied as a single, atomic change to the repository.</para>
+    @ENGLISH }}} -->
+    <para>Другими словами, если пользователь знает, что работа над веткой
+      будет проходить в конкретной директории, он может, с помощью,
+      <command>svn switch</command> переключить на ветку только эту
+      поддиректорию. (А иногда на ветку переключается только один
+      рабочий файл!) В этом случае пользователи могут продолжать
+      обычным образом получать обновления <quote>trunk</quote> для
+      большей части рабочей копии, а переключенные части будут оставаться
+      нетронутыми (до тех пор, пока кто-то не изменить этой ветки).
+      Эта возможность добавляет совершенно новое измерение в понятие
+      <quote>смешанная рабочая копия</quote> — рабочая копия может
+      содержать не только смесь рабочих правок но и смесь местоположений
+      в хранилище.</para>
+
+    <para>Если рабочая копия содержит какое-то количество переключенных
+      на разные местоположения в хранилище поддиректорий, она будет
+      продолжать нормально функционировать. При обновлении, патчи
+      соответственно будут приниматься для каждой поддиректории.
+      При фиксации, локальные модификации будут приниматься в хранилище
+      в виде единого, атомарного изменения.</para>
 
+    <!-- @ENGLISH {{{
     <para>Note that while it's okay for your working copy to reflect a
       mixture of repository locations, these locations must all be
       within the <emphasis>same</emphasis> repository.  Subversion
@@ -2818,13 +3078,27 @@
       that's a feature planned beyond Subversion
       1.0.<footnote><para>You <emphasis>can</emphasis>, however, use
       <command>svn switch</command> with the
-      <option>--relocate</option> switch if the URL of your server
+      <option>-ﳢ-relocate</option> switch if the URL of your server
       changes and you don't want to abandon an existing working copy.
       See the <command>svn switch</command> section in <xref
       linkend="svn.ref"/> for more information and an example.</para>
       </footnote></para>
+    @ENGLISH }}} -->
+    <para>Обратите внимание, на то, что хотя и иметь в рабочей копии
+      смесь местоположений в хранилище является нормальным, все эти
+      местоположения должны быть из <emphasis>одного</emphasis>
+      хранилища. Хранилища Subversion пока не могут сообщаться друг с
+      другом; реализация этой возможности запланирована после Subversion
+      1.0.<footnote><para>Однако, <emphasis>можно</emphasis>
+      воспользоваться <command>svn switch</command> с параметром
+      <option>--relocate</option> если URL сервервера изменился
+      и вы не хотите бросать существующую рабочую копию. За более
+      подробной информацией и примерами смотрите раздел, посвященный
+      <command>svn switch</command> в <xref linkend="svn.ref"/></para>
+      </footnote></para>
 
     <sidebar>
+      <!-- @ENGLISH {{{
       <title>Switches and Updates</title>
 
       <para>Have you noticed that the output of <command>svn
@@ -2854,8 +3128,37 @@
       <para>In other words, an update moves your working copy through
         time.  A switch moves your working copy through time
         <emphasis>and</emphasis> space.</para>
+      @ENGLISH }}} -->
+      <title>Переключения и обновления</title>
+
+      <para>Вы не обращали внимание на то, что вывод <command>svn
+        switch</command> и <command>svn update</command> выглядит
+        одинаково? На самом деле команда переключения является
+        расширеным вариантом команды обновления.</para>
+
+      <para>При запуске <command>svn update</command> вы просите
+        хранилище сравнить два дерева. Хранилище выполняет это
+        и отправляет описания изменений обратно клиенту. Отличие
+        между <command>svn switch</command> и <command>svn
+        update</command> только в том, что команда обновления
+        всегда сравнивает два одинаковых пути.</para>
+
+      <para>То есть, рабочая копия отражает <filename>/calc/trunk</filename>,
+        то <command>svn update</command> будет автоматически сравнивать
+        рабочую копию <filename>/calc/trunk</filename> с правкой
+         <literal>HEAD</literal> <filename>/calc/trunk</filename>.
+         Если вы переключаете рабочую копию на ветку, то <command>svn
+         switch</command> будет сравнивать рабочую копию
+         <filename>/calc/trunk</filename> с какой-то
+         <emphasis>другой</emphasis> директорией в правке
+         <literal>HEAD</literal>.</para>
+
+       <para>Другими словами, обновление переносит рабочую копию сквозь
+        время. А переключение переносит рабочую копию сквозь время
+        <emphasis>и</emphasis> пространство.</para>
     </sidebar>
 
+    <!-- @ENGLISH {{{
     <para>Because <command>svn switch</command> is essentially a
       variant of <command>svn update</command>, it shares the same
       behaviors; any local modifications in your working copy are
@@ -2869,6 +3172,19 @@
       switch</command> your working copy to the branch, the local
       changes will remain.  You can then test and commit them to the
       branch.</para>
+    @ENGLISH }}} -->
+    <para>Учитывая то, что <command>svn switch</command> в сущности
+      является разновидностью <command>svn update</command> их поведение
+      схоже; при получении новой информации из хранилища, все локальные
+      изменеия сохраняются. Это позволяет использовать разнообразные
+      трюки.</para>
+
+    <para>Предположим вы внесли некоторые изменения в имеющуюся у вас
+      рабочую копию <filename>/calc/trunk</filename>. После чего неожидано
+      обнаружили, что вместо этого вам необходимо внести изменения в ветку
+      Нет проблем! Когда вы переключите (<command>svn switch</command>)
+      рабочую копию на ветку, локальные изменения сохраняться. После чего
+      их можно проверить и зафиксировать в ветке.</para>
 
   </sect1>
 
@@ -2877,6 +3193,7 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.tags">
+    <!-- @ENGLISH {{{
     <title>Tags</title>
 
     <para>Another common version control concept is a
@@ -2892,15 +3209,37 @@
       After all, it's not so easy to remember that release-1.0 of a
       piece of software is a particular subdirectory of revision
       4822.</para>
+    @ENGLISH }}} -->
+    <title>Метки</title>
+
+    <para>Еще одним понятием, свойственным управлению версиями является
+      <firstterm>метка</firstterm>. Метка является просто
+      <quote>снимком</quote> проекта в определенный момент времени.
+      В Subversion эта идея уже, кажется, повсюду. Каждая правка хранилища
+      является именно этим — снимком файловой системы после каждой
+      фиксации.</para>
+
+    <para>Как правило, люди предпочитают давать меткам удобочитаемые имена,
+      наподобие <literal>release-1.0</literal>. И делать снимки небольших
+      поддиректорий файловой системы. Проще говоря, не просто запомнить, что
+      версия 1.0 программы соответствует поддиректории в правке 4822.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.tags.mksimple">
+      <!-- @ENGLISH {{{
       <title>Creating a Simple Tag</title>
 
       <para>Once again, <command>svn copy</command> comes to the
         rescue.  If you want to create a snapshot of
         <filename>/calc/trunk</filename> exactly as it looks in the
         <literal>HEAD</literal> revision, then make a copy of it:</para>
+      @ENGLISH }}} -->
+      <title>Создание простой метки</title>
+
+      <para>И снова приходит на помощь <command>svn copy</command>.
+        Если вам нужно сделать снимок <filename>/calc/trunk</filename>
+        в точно таком виде как в правке <literal>HEAD</literal>,
+        сделайте копию этой директории:</para>
 
 <screen>
 $ svn copy http://svn.example.com/repos/calc/trunk \
@@ -2910,6 +3249,7 @@
 Committed revision 351.
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>This example assumes that a
         <filename>/calc/tags</filename> directory already exists.  (If it
         doesn't, see <xref linkend="svn.ref.svn.c.mkdir"/>).
@@ -2935,7 +3275,33 @@
         as long as nobody ever commits to the directory, it forever
         remains a snapshot.  If people start committing to it, it
         becomes a branch.</para>
+      @ENGLISH }}} -->
+      <para>В этом примере предполагается, что директория
+        <filename>/calc/tags</filename> существует. (Если нет,
+        обратитесь к <xref linkend="svn.ref.svn.c.mkdir"/>).
+        После того как сделана копия, новая директория
+        <filename>release-1.0</filename> навсегда сохранит состояние
+        проекта в таком виде в каком он существовал в правке
+        <literal>HEAD</literal> на момент создания копии. Конечно,
+        можно более точно указать какую именно правку копировать,
+        возможна ситуация, когда кто-то другой зафиксировал изменения в
+        проекте с которыми вы еще не успели познакомиться. По-этому,
+        если вы знаете, что правка 350 <filename>/calc/trunk</filename>
+        это оиенно тот снимок который вам нужен, можете указать ее
+        передав <option>-r 350</option> команде <command>svn
+        copy</command>.</para>
+
+      <para>Постойте: ведь процедура создания метки такая-же как процедура
+        использованая нами при создании ветки? Да, фактически, это так.
+        Subversion не разделяет ветки и метки. И то и другое является
+        обычными директориями, создаными копированием. Как и в случае с
+        ветками, скопированная директория становиться <quote>меткой</quote>
+        только потому, что <emphasis>человек</emphasis> считает
+        ее таковой: если никто не делает фиксаций в эту директорию она
+        будет оставться снимком. Если в эту директорию начнут делать
+        фиксации она превратится в ветку.</para>
 
+      <!-- @ENGLISH {{{
       <para>If you are administering a repository, there are two
         approaches you can take to managing tags.  The first approach
         is <quote>hands off</quote>: as a matter of project policy,
@@ -2950,11 +3316,28 @@
         accidentally commits a change to a tag-directory, you can
         simply undo the change as discussed in the previous section.
         This is version control, after all.</para>
+      @ENGLISH }}} -->
+      <para>Если вы администрируете хранилище, есть два возможных подхода
+        управления метками. Первый подход <quote>ручной</quote>: в
+        соответствии с правилами проекта решите, где будут находиться
+        метки и убедитесь в том, что все пользователи знают как рассматривать
+        директории скопированные сюда. (То есть убедитесь, что они знают о
+        том что в них нельзя выполнять фиксации.) Второй подход более
+        параноидальный: вы можете воспользоваться одним из скриптов для
+        контроля доступа, поставляемым с Subversion для того, что бы никто
+        ничего другого кроме создания копий в области для создания меток
+        сделать немог. (См. <xref linkend="svn.serverconfig"/>.) Однако
+        обычно в параноидальном подходе необходимости нет. Если пользователь
+        непреднамеренно зафиксирует изменения в директорию с меткой,
+        вы можете просто отменить изменения, как это было рассмотрено в
+        преддыдущем разделе. Как ни как, это управление версиями.</para>
+
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.tags.mkcomplex">
+      <!-- @ENGLISH {{{
       <title>Creating a Complex Tag</title>
 
       <para>Sometimes you may want your <quote>snapshot</quote> to be
@@ -2982,6 +3365,31 @@
         different uses (which you can read about in Chapter 9),
         including the ability to copy a working-copy tree to the
         repository:</para>
+      @ENGLISH }}} -->
+      <title>Создание комплексной метки</title>
+
+      <para>Иногда вам будет необходим более сложный <quote>снимок</quote>,
+        чем одна единственная директория в одной правке.</para>
+
+      <para>Например, представим, что ваш проект гораздо больше, чем
+        наш пример <filename>calc</filename>: допустим он содержит
+        несколько поддиректорий и на много больше файлов. В процессе
+        работе вам может понадобиться создать рабочую копию, содержащую
+        конкретную функциональность и исправленные ошибки. Добиться этого
+        вы можете выборочно возвращая файлы или директории к конкретной
+        правке (используя <command>svn update -r</command> по мере
+        необходимости) или переключая файлы или директории на отдельные
+        ветки (применяя <command>svn switch</command>). По завершении
+        рабочаяя копия будет представлять собой мешанину различных
+        директорий и правок хранилища. После проверки вы поймете, что
+        вам нужна именно така комбинация.</para>
+
+      <para>Время создавать снимок. Копирование одного URL в другой
+        здесь не пройдет. Здесь нужно сделать и сохранить в хранилище снимок
+        именно такой структуры которую имеет рабочая копия. К счастью,
+        <command>svn copy</command> имет четыре способа использования
+        (о которых вы можете прочитать в в Главе 9), включая возможность
+        копировать в хранилище дерево рабочей копии:</para>
 
 <screen>
 $ ls
@@ -2992,6 +3400,7 @@
 Committed revision 352.
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>Now there is a new directory in the repository,
         <filename>/calc/tags/mytag</filename>, which is an exact
         snapshot of your working copy—mixed revisions, URLs,
@@ -3007,6 +3416,21 @@
         of the repository.  Your collaborator can then either checkout
         a verbatim copy of your working copy, or use <command>svn
         merge</command> to receive your exact changes.</para>
+      @ENGLISH }}} -->
+      <para>Теперь в хранилище есть новая директория
+      <filename>/calc/tags/mytag</filename> которая является полным отражением
+        рабочей копии — смешаные правки, URL, и тому подобное.</para>
+
+      <para>Некоторые пользователи находят интересное применение этой
+        возможности. Иногда возникают ситуации, когда в вашей рабочей копии
+        содержаться изменения, которые вы не хотите показывать соразработчику.
+        Вместо запуска <command>svn diff</command> и передачи патч-файла
+        (который не сможет отразить изменения в структуре файлов), вы можете
+        воспользоваться <command>svn copy</command> для
+        <quote>загрузки</quote> рабочей копии в отдельную область хранилища.
+        Ваш соразработчик может сделать либо чистую копию вашей рабочей копии,
+        либо воспользоваться <command>svn merge</command> для получения именно
+        ваших изменений.</para>
 
     </sect2>
 
@@ -3016,6 +3440,7 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.maint">
+    <!-- @ENGLISH {{{
     <title>Branch Maintenance</title>
 
     <para>You may have noticed by now that Subversion is extremely
@@ -3025,9 +3450,20 @@
       Subversion intimidating.  It's almost <emphasis>too</emphasis>
       flexible.  In this section, we'll offer some suggestions for
       arranging and managing your data over time.</para>
+    @ENGLISH }}} -->
+    <title>Поддержка веток</title>
+
+    <para>Сейчас вы уже понимаете, что Subversion очень гибкая система.
+      Учитывая то, что ветки и метки имеют одну и ту же основу (копии
+      директорий), а так-же то, что ветки и метки являются обычными элементами
+      файловой системы, Subversion многих пугает. Она
+      <emphasis>слишком</emphasis> гибкая. В этом разделе мы предложим
+      несколько советов по компоновке и поддержке информации с течением
+      времени.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.maint.layout">
+      <!-- @ENGLISH {{{
       <title>Repository Layout</title>
 
       <para>There are some standard, recommended ways to organize a
@@ -3037,6 +3473,17 @@
         copies, and a <filename>tags</filename> directory to contain
         tag copies.  If a repository holds only one project, then
         often people create these top-level directories:</para>
+      @ENGLISH }}} -->
+      <title>Структура хранилища</title>
+
+      <para>Существует несколько стандартных, рекомендуемых способов
+        организации хранилища. Как правило, создается директория
+        <filename>trunk</filename>, в которой находится
+        <quote>главная линия</quote> разработки, директория
+        <filename>branches</filename> для хранения веток и директория
+        <filename>tags</filename> для хранения меток. Если хранилище
+        содержит только один проект, обычно создают три директории
+        верхнего уровня:</para>
 
 <screen>
 /trunk
@@ -3044,10 +3491,17 @@
 /tags
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>If a repository contains multiple projects, admins
         typically index their layout by project (see <xref
         linkend="svn.reposadmin.projects.chooselayout"/> to read more about
         <quote>project roots</quote>):</para>
+      @ENGLISH }}} -->
+      <para>Если хранилище содержит несколько проектов, администратор,
+        обычно создает такую структуру для каждого проекта отдельно
+        (за более подробной информацией о <quote>корне проекта</quote>
+        обратитесь в раздел <xref
+        linkend="svn.reposadmin.projects.chooselayout"/>):</para>
 
 <screen>
 /paint/trunk
@@ -3058,6 +3512,7 @@
 /calc/tags
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>Of course, you're free to ignore these common layouts.
         You can create any sort of variation, whatever works best for
         you or your team.  Remember that whatever you choose, it's not
@@ -3080,11 +3535,34 @@
         longer exists, and the user will be forced to <command>svn
         switch</command> to the new location.
         </para>
+      @ENGLISH }}} -->
+      <para>Конечно, вы можете не использовать такие типовые структуры.
+        Вы можете сделать любую разновидность, которая будет удобна для вас
+        или вашей комманды. Помните о том, какой бы вы вабор не сделали,
+        он может быть не окончательным. Хранилище можно реарганизовать в
+        любое время. Учитывая то, что ветки и метки являются обычными
+        директориями, команда <command>svn move</command> может переместить
+        или переименовать их по вашему усмотрению. Переход от одной структуры
+        к другой означает просто несколько последовательных передвижек
+        на сервере; если организация хранилища вам не нравится, просто
+        поменяйте местами директории.</para>
+
+      <para>Однако не забывайте о том, что несмотря на легкость перемещения
+        директорий, нужно помнить и о других пользователях. Ваши перестановки
+        могут дезориентировать пользователей с существующими рабочими копиями.
+        Если у пользователя есть робочая копия отдельной директории хранилища,
+        то ваше использование <command>svn move</command> может удалить этот
+        путь из последней правки. Когда в очередной раз пользователь запустит
+        <command>svn update</command>, он будет проинформирован о том, что
+        его рабочая копия отражает путь, который больше не существует,
+        и пользователь будет вынужден переключиться (<command>svn
+        switch</command>) на новое местоположение.</para>
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.maint.lifetime">
+      <!-- @ENGLISH {{{
       <title>Data Lifetimes</title>
 
       <para>Another nice feature of Subversion's model is that
@@ -3095,6 +3573,16 @@
         changes back into <filename>/calc/trunk</filename>, there's
         no need for your private branch directory to stick around
         anymore:</para>
+      @ENGLISH }}} -->
+      <title>Продолжителность жизни информации</title>
+
+      <para>Еще одним замечательным свойством модели Subversion
+        является то, что ветки и метки могут иметь конечную
+        продолжительность жизни, так же как и все другие версионированные
+        элементы. Например, предположим вы наконец закончили все работы
+        в ваше личной ветке проекта <filename>calc</filename>. После
+        объединения изменений с  <filename>/calc/trunk</filename>,
+        нет причин продолжать хранить эту ветку:</para>
 
 <screen>
 $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
@@ -3103,6 +3591,7 @@
 Committed revision 375.
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>And now your branch is gone.  Of course it's not really
         gone: the directory is simply missing from the
         <literal>HEAD</literal> revision, no longer distracting
@@ -3117,6 +3606,20 @@
         you'd like to bring back into <literal>HEAD</literal>, simply
         use <command>svn copy -r</command> to copy it from the old
         revision:</para>
+      @ENGLISH }}} -->
+      <para>Больше вашей ветки не существует. Конечно, на самом деле она
+        не исчезла: просто ее больше нет в правке <literal>HEAD</literal>,
+        она больше никого не отвлекает. Если воспользоваться командами
+        <command>svn checkout</command>, <command>svn switch</command>
+        или <command>svn list</command> для обращения к ранним правкам,
+        свою старую ветку вы увидите.</para>
+
+      <para>Если просмотра удаленной директирии не достаточно, вы всегда
+        можете востановить эту директорию. Востановление информации в
+        Subversion выполнить очень просто. Если есть директория или файл,
+        который вы хотите вернуть обратно в <literal>HEAD</literal>,
+        просто воспользуйтесь <command>svn copy -r</command> для того,
+        что бы скопировать его из старой правки:</para>
 
 <screen>
 $ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
@@ -3125,6 +3628,7 @@
 Committed revision 376.
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>In our example, your personal branch had a relatively
         short lifetime: you may have created it to fix a bug or
         implement a new feature.  When your task is done, so is the
@@ -3138,6 +3642,20 @@
         developers to stop programming either.  So instead, you create
         a <quote>stable</quote> branch of the software that won't
         change much:</para>
+      @ENGLISH }}} -->
+      <para>В нашем примере ваша личная ветка имеет относительно
+        короткую продолжительность жизни: возможно она создавалась
+        для того, что бы исправить ошибку или реализовать новую функцию.
+        После того, как работа завершена, завершена и ветка. При разработке
+        программного обеспечения, тем не менее, часто имеют две
+        <quote>главных</quote> ветки, существующих рядом довольно долгое
+        время. Допустим, пришло время вупустить релиз стабилизировавшегося
+        проекта <filename>calc</filename>, а вы знаете, что нужна будет пара
+        месяцев для того, что бы вытрясти из программы последние ошибки.
+        Разработчики не должны добавлять в проект новых функции, но при этом
+        и работа не должна останавлиться. В подобной ситуации создается
+        <quote>стабильная</quote> ветка программы, которая существенно
+        изменяться уже не будет:</para>
 
 <screen>
 $ svn copy http://svn.example.com/repos/calc/trunk \
@@ -3147,6 +3665,7 @@
 Committed revision 377.
 </screen>
 
+      <!-- @ENGLISH {{{
       <para>And now developers are free to continue adding
         cutting-edge (or experimental) features to
         <filename>/calc/trunk</filename>, and you can declare a
@@ -3157,6 +3676,17 @@
         stable branch has shipped, you'll probably continue to
         maintain the branch for a long time—that is, as long
         as you continue to support that release for customers.</para>
+      @ENGLISH }}} -->
+      <para>После этого, разработчикам ничего не мешает продолжать добавлять
+        в <filename>/calc/trunk</filename> новые передовые (или эксперементальные)
+        функции, а в правилах проекта можно указать, что в
+        <filename>/calc/branches/stable-1.0</filename> должны фиксироваться
+        только исправления ошибок. По мере того, как будет продвигаться
+        работа над главной линией разработки, исправленые ошибки будут
+        выборочно портироваться в стабильную ветку. Даже после выхода релиза
+        стабильной ветки, она может продолжать поддерживаться долгое время
+        — столько, сколько этот релиз будет продолжать поддерживаться
+        для пользователей.</para>
 
     </sect2>
 
@@ -3167,6 +3697,7 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.summary">
+    <!-- @ENGLISH {{{
     <title>Summary</title>
 
     <para>We've covered a lot of ground in this chapter.  We've
@@ -3182,6 +3713,20 @@
 
     <para>Remember the Subversion mantra: branches and tags are cheap.
       So use them liberally!</para>
+    @ENGLISH }}} -->
+    <title>Подводя итоги</title>
+
+    <para>В этой главе было рассмотренно очень многое. Мы обсудили
+      концепцию меток и веток, показали как Subversion реализует эти понятия
+      используя комманду <command>svn copy</command>. Показали, как
+      <command>svn merge</command> копирует изменения из одной ветки в другую,
+      как с помощью этой комманды отменить ошибочные изменения. Мы рассмотрели
+      использование <command>svn switch</command> для создания рабочих копий,
+      собранных из разных директорий хранилища. Обсудили, как управлять
+      организацией и временем жизни веток в хранилище.</para>
+
+    <para>Не забывайте о мантре Subversion: ветки и метки легковесны. По-этому
+      пользуйтесь ими свободно!</para>
 
   </sect1>
 



More information about the svnbook-dev mailing list