[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