[svnbook commit] r1530 - trunk/src/ru/book
dmitriy
svnbook-dev at red-bean.com
Sat Jul 9 05:04:39 CDT 2005
Author: dmitriy
Date: Sat Jul 9 05:04:38 2005
New Revision: 1530
Modified:
trunk/src/ru/book/ch04.xml
Log:
* ru/book/ch04.xml
Translation for 'svn.branchmerge.whatis' and 'svn.branchmerge.using' now
finished, start of translation for 'svn.branchmerge.using.create'
Modified: trunk/src/ru/book/ch04.xml
==============================================================================
--- trunk/src/ru/book/ch04.xml (original)
+++ trunk/src/ru/book/ch04.xml Sat Jul 9 05:04:38 2005
@@ -70,6 +70,7 @@
внести небольшие изменения, вы включаете их или в одну копию или
в другую.</para>
+ <!-- @ENGLISH {{{
<para>You often want to make the same change to both copies. For
example, if you discover a typo in the first copy, it's very
likely that the same typo exists in the second copy. The two
@@ -83,7 +84,22 @@
branch always begins life as a copy of something, and moves on
from there, generating its own history (see <xref
linkend="svn.branchmerge.whatis.dia-1"/>).</para>
+ @ ENGLISH }}} -->
+ <para>Как правило, вам будет нужно вносить изменения в обе копии.
+ Например, если вы обнаружили опечатку в одной копии, скорее
+ всего, эта же опечатка присутствует и во второй копии.
+ Два документа вобщем то одинаковые; отличиются они незначительно
+ в отдельных, специфичных моментах.</para>
+
+ <para>В этом заключается основная идея
+ <firstterm>ветки</firstterm> — а именно, направления разработки,
+ которое существует независимо от другого направления, однако
+ имеющие с ним общую историю, если заглянуть немного в прошлое.
+ Ветка всегда берет начало как копия чего-либо и двигается от
+ этого момента создавая свою собственную историю (см. <xref
+ linkend="svn.branchmerge.whatis.dia-1"/>).</para>
+ <!-- @ENGLISH {{{
<figure id="svn.branchmerge.whatis.dia-1">
<title>Branches of development</title>
<graphic fileref="images/ch04dia1.png"/>
@@ -97,6 +113,20 @@
your working copy reflect different branches, so that you can
<quote>mix and match</quote> different lines of development in
your daily work.</para>
+ @ ENGLISH }}} -->
+ <figure id="svn.branchmerge.whatis.dia-1">
+ <title>Ветки разработки</title>
+ <graphic fileref="images/ch04dia1.png"/>
+ </figure>
+
+ <para>У Subversion есть команды, которые помогают сопровождать
+ паралельные ветки файлов и директорий. Эти команды позволяют создавать
+ ветки, копируя информацию и запоминая, что копии относятся
+ друг к другу. Кроме того эти команды помогают дублировать изменения
+ из одной ветки в другую. Наконец, они могут сделать отдельные части
+ рабочей копии отвечающими отдельным веткам, что позволит вам
+ <quote>смешивать и согласовывать</quote> различные направления
+ разработки в своей каждодневной работе.</para>
</sect1>
@@ -104,6 +134,7 @@
<!-- ================================================================= -->
<!-- ================================================================= -->
<sect1 id="svn.branchmerge.using">
+ <!-- @ENGLISH {{{
<title>Using Branches</title>
<para>At this point, you should understand how each commit creates
@@ -119,12 +150,32 @@
project directory now contains subdirectories named
<filename>trunk</filename> and <filename>branches</filename>.
The reason for this will soon become clear.</para>
+ @ ENGLISH }}} -->
+ <title>Использование веток</title>
+
+ <para>К этому моменту вы должны понимать как в хранилище, при каждой
+ фиксации, создается поностью новое дерево файлов (называемое
+ <quote>правка</quote>). Если нет, то вернитесь назад и прочитайте
+ раздел <xref linkend="svn.basic.in-action.revs"/>.</para>
+
+ <para>Для этой главы, мы воспользуемся тем же примером, что и
+ в Главе 2. Как вы помните, вы и ваш соразработчик Салли
+ делите хранилище, содержащее два проекта, <filename>paint</filename>
+ и <filename>calc</filename>. Как показывает <xref
+ linkend="svn.branchmerge.using.dia-1"/> каждая директория проекта
+ содержит поддиректории с названиями <filename>trunk</filename> и
+ <filename>branches</filename>. Назначение этих директорий скоро
+ станет понятно.</para>
<figure id="svn.branchmerge.using.dia-1">
+ <!-- @ENGLISH {{{
<title>Starting repository layout</title>
+ @ ENGLISH }}} -->
+ <title>Начальная структура хранилища</title>
<graphic fileref="images/ch04dia2.png"/>
</figure>
+ <!-- @ENGLISH {{{
<para>As before, assume that Sally and you both have working
copies of the <quote>calc</quote> project. Specifically, you
each have a working copy of <filename>/calc/trunk</filename>.
@@ -143,7 +194,24 @@
<filename>/calc/trunk</filename>) is always usable. If you
start committing your changes bit-by-bit, you'll surely break
things for Sally.</para>
+ @ ENGLISH }}} -->
+ <para>Как и раньше, будем считать что Салли и вы, оба, имеете
+ рабочие копии проекта <quote>calc</quote>. А конкретно, каждый
+ из вас имеет рабочую копию <filename>/calc/trunk</filename>.
+ Все файлы относящиеся к проекту находятся в этой поддиректории,
+ а не прямо в <filename>/calc</filename>, потому, что ваша команда
+ решила размещать главную линию разработки в
+ <filename>/calc/trunk</filename>.</para>
+
+ <para>Скажем, перед вами была поставлена задача коренной реорганизации
+ проекта. Это займет много времени и затронет все файлы проекта.
+ Проблема заключается в том, что вы не хотите мешать Салли, котороя
+ прямо сейчас занимается исправлением небольших ошибок. Ее работа
+ зависит от постоянной доступности последней версии проекта (директории
+ <filename>/calc/trunk</filename>). Если вы начнете пошагово фиксировать
+ свои изменения, вы конечно же смешаете Салли все карты.</para>
+ <!-- @ENGLISH {{{
<para>One strategy is to crawl into a hole: you and Sally can stop
sharing information for a week or two. That is, start gutting
and reorganizing all the files in your working copy, but don't
@@ -167,16 +235,50 @@
that are difficult to incorporate into your working
copy—especially if you run <command>svn update</command>
after weeks of isolation.</para>
+ @ ENGLISH }}} -->
+ <para>Одиним из вариантов является ограничение свободы действий:
+ вы и Салли перестаете делиться информацией на неделю или две.
+ В это время начинайте переворачивать и реорганизовывать файлы
+ рабочей копии, но не фиксируйте и не обновляйте ее пока не
+ закончите эту задачу. Однако в этом случаее появляется несколько
+ проблем. Во-первых это не очень надежно. Большинство людей
+ предпочитают часто сохранять свою работу в хранилище, на случай если
+ вдруг что-то плохое случится с рабочей копией. Во-вторых, это не
+ достаточно гибко. Если вы работаете на разных компьютерах
+ (к примеру если рабочая копия <filename>/calc/trunk</filename>
+ есть у вас на разных машинах), вам придется вручную копировать
+ изменения взад и вперед, либо делать всю работу на одном
+ компьютере. А с другой стороны, вам трудно разделять вносимые
+ изменения с кем-то еще. Общий при разработке програмного обеспечения
+ <quote>лучший метод организации</quote> это возможность
+ совместного просмотра проделаной работы по мере продвижения.
+ Если никто не видит ваших промежуточных фиксаций, вы теряете
+ потенциальную возможность обратной связи. В конце концов, когда вы
+ закончите свои изменения, вы можете обнаружить, что очень трудно
+ заново слить сделаную вами работу с остальным програмным кодом
+ компании. Салли или (кто-то другой) могли внести изменения в
+ хранилище, которые будет трудно внедрить в вашу рабочую копию
+ — особенно если вы выполните <command>svn update</command>
+ после нескольких недель изоляции.</para>
+
+ <!-- @ENGLISH {{{
<para>The better solution is to create your own branch, or line of
development, in the repository. This allows you to save your
half-broken work frequently without interfering with others, yet
you can still selectively share information with your
collaborators. You'll see exactly how this works later
on.</para>
+ @ ENGLISH }}} -->
+ <para>Лучшим решением является создание вашей собственной ветки, или
+ направления разработки, в хранилище. Это позволит вам часто сохранять
+ наполовину поломаную работу не пересекаясь с другими, и кроме того,
+ вы можете выборочно разделять информацию с другими соразработчиками.
+ Дальше по тексту вы увидите как все это работает.</para>
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.using.create">
+ <!-- @ENGLISH {{{
<title>Creating a Branch</title>
<para>Creating a branch is very simple—you make a copy of
@@ -199,6 +301,27 @@
demonstrate the messy way first, just to make the concept
clear. To begin, check out a working copy of the project's
root directory, <filename>/calc</filename>:</para>
+ @ ENGLISH }}} -->
+ <title>Создание ветки</title>
+
+ <para>Создать ветку очень просто — при помощи команды
+ <command>svn copy</command> делаете в хранилище копию проекта.
+ Subversion может копировать не только отдельные файлы но и
+ директории. Итак, вам нужно сделать копию директории
+ <filename>/calc/trunk</filename>. Где эта новая копия будет
+ находится? Где угодно — этот вопрос определяется
+ правилами проекта. Допустим, что правилами вашей команды определено
+ создание веток в директории <filename>/calc/branches</filename>
+ хранилища, и свою ветку вы хотите назвать
+ <literal>my-calc-branch</literal>. Вам необходимо создать новую
+ директорию <filename>/calc/branches/my-calc-branch</filename>
+ которая будет являться копией
+ <filename>/calc/trunk</filename>.</para>
+
+ <para>Есть два способа создания копии. Сначала мы покажем
+ неудачный способ, просто для того, что бы прояснить основные моменты.
+ Для начала, создается рабочая копия корневой директории проекта
+ <filename>/calc</filename>:</para>
<screen>
$ svn checkout http://svn.example.com/repos/calc bigwc
@@ -210,9 +333,14 @@
Checked out revision 340.
</screen>
+ <!-- @ENGLISH {{{
<para>Making a copy is now simply a matter of passing two
working-copy paths to the <command>svn copy</command>
command:</para>
+ @ ENGLISH }}} -->
+ <para>Теперь создание копии заключается в простой предаче
+ двух путей в пределах рабочей копии команде
+ <command>svn copy</command>:</para>
<screen>
$ cd bigwc
@@ -221,6 +349,7 @@
A + branches/my-calc-branch
</screen>
+ <!-- @ENGLISH {{{
<para>In this case, the <command>svn copy</command> command
recursively copies the <filename>trunk</filename> working
directory to a new working directory,
@@ -235,6 +364,21 @@
repository by copying <filename>/calc/trunk</filename>, rather
than resending all of the working copy data over the
network:</para>
+ @ ENGLISH }}} -->
+ <para>В этом случае, команда <command>svn copy</command>
+ рекурсивно копирует рабочую директорию <filename>trunk</filename>
+ в новую рабочую директорию
+ <filename>branches/my-calc-branch</filename>. Теперь команда
+ <command>svn status</command> покажет, что новая директория
+ запланирована для добавления в хранилище. Обратите внимание
+ на знак <quote>+</quote> после буквы А. Это означает, что
+ то что запланировано для добавления является
+ <emphasis>копией</emphasis> чего-то, а не чем-то новым.
+ При следующей фиксации, Subversion создаст в хранилище путем
+ копирования дириктории <filename>/calc/trunk</filename>
+ директорию <filename>/calc/branches/my-calc-branch</filename>,
+ вместо повторного отправления через сеть всей информации
+ рабочей копии:</para>
<screen>
$ svn commit -m "Creating a private branch of /calc/trunk."
@@ -242,9 +386,14 @@
Committed revision 341.
</screen>
+ <!-- @ENGLISH {{{
<para>And now the easier method of creating a branch, which we
should have told you about in the first place: <command>svn
copy</command> is able to operate directly on two URLs.</para>
+ @ ENGLISH }}} -->
+ <para>А теперь, простой способ создания ветки, о котором мы говорили
+ раньше: команда <command>svn copy</command> может оперировать
+ с двумя URL напрямую.</para>
<screen>
$ svn copy http://svn.example.com/repos/calc/trunk \
@@ -254,6 +403,7 @@
Committed revision 341.
</screen>
+ <!-- @ENGLISH {{{
<para>There's really no difference between these two methods.
Both procedures create a new directory in revision 341, and
the new directory is a copy of
@@ -270,6 +420,20 @@
check out a large mirror of the repository. In fact, this
technique doesn't even require you to have a working copy at
all.</para>
+ @ ENGLISH }}} -->
+ <para>Всущности, между этими двумя методами нет разници. Оба варианта
+ создают в правке 341 новую директорию и эта новая директория является
+ копией <filename>/calc/trunk</filename>. Это показывает <xref
+ linkend="svn.branchmerge.using.create.dia-1"/>. Обратите внимание на
+ то, что второй метод, кроме прочего, выполняет
+ <emphasis>немедленную</emphasis> фиксацию. <footnote><para>Subversion
+ не поддерживает возможность копирования между хранилищами. При использовании
+ в командах <command>svn copy</command> или <command>svn move</command> URL,
+ можно копировать только элементы из одного и того же хранилища.</para>
+ </footnote>Эта процедура более проста в использовании, так как нет
+ необходимости в создании рабочей копии, отражающей большое хранилище.
+ Фактически, в этом случае вам вовсе можно не иметь рабочей
+ копии.</para>
<figure id="svn.branchmerge.using.create.dia-1">
<title>Repository with new copy</title>
More information about the svnbook-dev
mailing list