[svnbook commit] r3313 - trunk/src/ru/book
Imaged
noreply at red-bean.com
Tue Sep 16 16:56:28 CDT 2008
Author: Imaged
Date: Tue Sep 16 16:56:27 2008
New Revision: 3313
Log:
* ru/book/ch-branching-and-merging.xml: essential fixes of stylistics
Modified:
trunk/src/ru/book/ch-branching-and-merging.xml
Modified: trunk/src/ru/book/ch-branching-and-merging.xml
==============================================================================
--- trunk/src/ru/book/ch-branching-and-merging.xml (original)
+++ trunk/src/ru/book/ch-branching-and-merging.xml Tue Sep 16 16:56:27 2008
@@ -19,17 +19,18 @@
assumes that you're already familiar with Subversion's basic
concepts (<xref linkend="svn.basic"/>).</para>
@ENGLISH }}} -->
- <para>Ветвление, назначение меток и слияние понятия свойственные
- практически всем системам управления версиями. Если вы плохо
- знакомы с этими понятиями, то в этой главе мы предлагаем хорошее
- введение. Если эти понятия вам знакомы, тогда надеемся что вам будет
- интересно узнать как эти идеи реализует Subversion.</para>
-
- <para>Ветвление это фундаментальное понятие управления версиями.
- Если вы доверили Subversion управлять своей информацией, то эта
- функция от которой со временем вы будете зависеть. Эта глава
- предполагает, что вы уже знакомы с основными понятиями
- Subversion (<xref linkend="svn.basic"/>).</para>
+ <para>Ветвление, назначение меток и слияние — это понятия,
+ свойственные практически всем системам управления версиями. Если
+ вы плохо знакомы с этими понятиями, то в этой главе вы с ними
+ обстоятельно познакомитесь. Если эти понятия вам уже знакомы,
+ то мы надеемся, что вам будет интересно узнать, как эти идеи
+ реализованы в Subversion.</para>
+
+ <para>Ветвление — фундаментальное понятие управления версиями.
+ Если вы собираетесь доверить Subversion управление своей информацией,
+ то это именно та функция, от которой вы впоследствии будете сильно
+ зависеть. Материал данной главы предполагает, что вы уже знакомы
+ с основными понятиями Subversion (<xref linkend="svn.basic"/>).</para>
<!-- ================================================================= -->
<!-- ================================================================= -->
@@ -54,17 +55,17 @@
<title>Что такое ветка?</title>
<para>Предположим, что ваша работа заключается в сопровождении
- документа, например какого-то руководства, для подразделений
- в вашей компании. Однажды различные подразделения запросят у вас
- одно и тоже руководство, но с несколькими частями которые будут
- немного <quote>подредактированны</quote>, так как задачи у них
- немного различаются.</para>
-
- <para>Как вы поступите в такой ситуации? Вы делаете очевидную вещь:
- создаете вторую копию документа и начинаете сопровождать две
- отдельных копии. Когда какое-то из подразделений просит вас
- внести небольшие изменения, вы включаете их или в одну копию или
- в другую.</para>
+ документа (например, какого-то руководства) для подразделений
+ вашей компании. Однажды различные подразделения запросят
+ у вас одно и то же руководство, но при этом в несколько
+ <quote>адаптированном</quote> для них варианте, поскольку
+ работа каждого подразделения имеет свою специфику.</para>
+
+ <para>Как вы поступите в такой ситуации? Очевидно, вы сделаете так:
+ создадите вторую копию документа и начнёте отдельно сопровождать
+ обе копии. Когда какое-то из подразделений попросит вас
+ внести небольшие изменения, вы включите их либо в первую копию,
+ либо во вторую.</para>
<!-- @ENGLISH {{{
<para>You often want to make the same change to both copies. For
@@ -81,18 +82,18 @@
from there, generating its own history (see <xref
linkend="svn.branchmerge.whatis.dia-1"/>).</para>
@ENGLISH }}} -->
- <para>Как правило, вам будет нужно вносить изменения в обе копии.
- Например, если вы обнаружили опечатку в одной копии, скорее
- всего, эта же опечатка присутствует и во второй копии.
- Два документа в общем то одинаковые; отличаются они незначительно
- в отдельных, специфичных моментах.</para>
+ <para>Чаще всего вам придется вносить изменения в обе копии.
+ Например, если вы обнаружите опечатку в одной копии, скорее
+ всего, эта же опечатка будет присутствовать и в другой.
+ Два документа, в общем-то, почти одинаковы — их различия
+ сводятся к отдельным специфичным моментам.</para>
<para>В этом заключается основная идея
- <firstterm>ветки</firstterm> — а именно, направления разработки,
- которое существует независимо от другого направления, однако
- имеющие с ним общую историю, если заглянуть немного в прошлое.
- Ветка всегда берет начало как копия чего-либо и двигается от
- этого момента создавая свою собственную историю (см. <xref
+ <firstterm>ветки</firstterm> — то есть направления разработки,
+ которое существует независимо от другого направления, но
+ имеет с ним общую историю, если заглянуть немного в прошлое.
+ Ветка всегда берет начало как копия чего-либо и движется от
+ этой точки, создавая свою собственную историю (см. <xref
linkend="svn.branchmerge.whatis.dia-1"/>).</para>
<!-- @ENGLISH {{{
@@ -115,14 +116,14 @@
<graphic fileref="images/ch04dia1.png"/>
</figure>
- <para>У Subversion есть команды, которые помогают сопровождать
- параллельные ветки файлов и директорий. Эти команды позволяют создавать
- ветки, копируя информацию и запоминая, что копии относятся
- друг к другу. Кроме того эти команды помогают дублировать изменения
- из одной ветки в другую. Наконец, они могут сделать отдельные части
- рабочей копии отвечающими отдельным веткам, что позволит вам
- <quote>смешивать и согласовывать</quote> различные направления
- разработки в своей каждодневной работе.</para>
+ <para>В Subversion есть команды, которые помогают сопровождать
+ параллельные ветки файлов и каталогов. Они позволяют создавать
+ ветки, копируя данные и запоминая, что копии связаны
+ друг с другом. Кроме того, эти команды помогают дублировать изменения
+ из одной ветки в другую. Наконец, они могут сделать так, что отдельные
+ части рабочей копии будут отражать состояние различных веток,
+ что позволит вам <quote>смешивать и согласовывать</quote> различные
+ линии разработки в своей каждодневной работе.</para>
</sect1>
@@ -150,19 +151,19 @@
@ENGLISH }}} -->
<title>Использование веток</title>
- <para>К этому моменту вы должны понимать как в хранилище, при каждой
- фиксации, создается полностью новое дерево файлов (называемое
+ <para>К этому моменту вы должны понимать, что в хранилище при каждой
+ фиксации создается полностью новое дерево файлов (называемое
<quote>правка</quote>). Если нет, то вернитесь назад и прочитайте
- раздел <xref linkend="svn.basic.in-action.revs"/>.</para>
+ о правках в разделе <xref linkend="svn.basic.in-action.revs"/>.</para>
- <para>Для этой главы, мы воспользуемся тем же примером, что и
+ <para>В этой главе мы воспользуемся тем же примером, что и
в <xref linkend="svn.basic"/>. Как вы помните, вы и ваш соразработчик
- Салли делите хранилище, содержащее два проекта,
+ Салли совместно используете хранилище, содержащее два проекта,
<filename>paint</filename> и <filename>calc</filename>. Как
- показывает <xref linkend="svn.branchmerge.using.dia-1"/> каждая
- директория проекта содержит поддиректории с названиями
+ отмечалось в <xref linkend="svn.branchmerge.using.dia-1"/>, каждый
+ каталог проекта содержит подкаталоги с именами
<filename>trunk</filename> и <filename>branches</filename>.
- Назначение этих директорий скоро станет понятно.</para>
+ Назначение этих каталогов вскоре станет понятно.</para>
<figure id="svn.branchmerge.using.dia-1">
<!-- @ENGLISH {{{
@@ -192,19 +193,19 @@
start committing your changes bit-by-bit, you'll surely break
things for Sally.</para>
@ENGLISH }}} -->
- <para>Как и раньше, будем считать что Салли и вы, оба, имеете
- рабочие копии проекта <quote>calc</quote>. А конкретно, каждый
+ <para>Как и раньше, предположим, что и Салли, и вы имеете
+ рабочие копии проекта <quote>calc</quote>. Точнее, каждый
из вас имеет рабочую копию <filename>/calc/trunk</filename>.
- Все файлы относящиеся к проекту находятся в этой поддиректории,
- а не прямо в <filename>/calc</filename>, потому, что ваша команда
- решила размещать главную линию разработки в
+ Все файлы, относящиеся к проекту, находятся в этом подкаталоге,
+ а не прямо в <filename>/calc</filename>, потому что ваша команда
+ решила размещать <quote>главную линию</quote> разработки в
<filename>/calc/trunk</filename>.</para>
- <para>Скажем, перед вами была поставлена задача коренной реорганизации
+ <para>Допустим, перед вами была поставлена задача коренной реорганизации
проекта. Это займет много времени и затронет все файлы проекта.
Проблема заключается в том, что вы не хотите мешать Салли, которая
прямо сейчас занимается исправлением небольших ошибок. Ее работа
- зависит от постоянной доступности последней версии проекта (директории
+ зависит от постоянной доступности последней версии проекта (каталога
<filename>/calc/trunk</filename>). Если вы начнете пошагово фиксировать
свои изменения, вы конечно же смешаете Салли все карты.</para>
@@ -233,30 +234,31 @@
copy—especially if you run <command>svn update</command>
after weeks of isolation.</para>
@ENGLISH }}} -->
- <para>Одним из вариантов является ограничение свободы действий:
+ <para>Одним из вариантов является временная изоляция:
вы и Салли перестаете делиться информацией на неделю или две.
- В это время начинайте переворачивать и реорганизовывать файлы
- рабочей копии, но не фиксируйте и не обновляйте ее пока не
- закончите эту задачу. Однако в этом случае появляется несколько
- проблем. Во-первых это не очень надежно. Большинство людей
- предпочитают часто сохранять свою работу в хранилище, на случай если
- вдруг что-то плохое случится с рабочей копией. Во-вторых, это не
+ В это время вы начинаете перелопачивать и реорганизовывать файлы
+ рабочей копии, но не фиксируете и не обновляете ее до завершения
+ работы над задачей. Однако, в этом случае появляется несколько
+ проблем. Во-первых, это не очень надежно. Большинство людей
+ предпочитают часто сохранять свою работу в хранилище на случай, если
+ с рабочей копией вдруг случится что-то плохое. Во-вторых, это не
достаточно гибко. Если вы работаете на разных компьютерах
- (к примеру если рабочая копия <filename>/calc/trunk</filename>
- есть у вас на разных машинах), вам придется вручную копировать
- изменения взад и вперед, либо делать всю работу на одном
- компьютере. А с другой стороны, вам трудно разделять вносимые
- изменения с кем-то еще. Общий при разработке программного обеспечения
- <quote>лучший метод организации</quote> это возможность
- совместного просмотра проделанной работы по мере продвижения.
- Если никто не видит ваших промежуточных фиксаций, вы теряете
- потенциальную возможность обратной связи. В конце концов, когда вы
- закончите свои изменения, вы можете обнаружить, что очень трудно
- заново слить сделанную вами работу с остальным программным кодом
- компании. Салли или (кто-то другой) могли внести изменения в
- хранилище, которые будет трудно внедрить в вашу рабочую копию
- — особенно если вы выполните <command>svn update</command>
- после нескольких недель изоляции.</para>
+ (к примеру, если рабочая копия <filename>/calc/trunk</filename>
+ есть у вас на двух разных машинах), вам придется вручную копировать
+ изменения туда и обратно, либо делать всю работу на одном
+ компьютере. С другой стороны, вам трудно делиться вносимыми
+ изменениями с кем-то еще. А предоставление возможности
+ знакомиться с проделанной вами работой по мере ее продвижения
+ считается <quote>наилучшей практикой</quote> при разработке
+ любого программного обеспечения. Если никто не будет видеть
+ ваших промежуточных фиксаций, вы теряете
+ потенциал обратной связи. Наконец, когда вы закончите свои
+ изменения, может выясниться, что слить проделанную вами работу
+ с остальным программным кодом компании чрезвычайно трудно.
+ Салли (или кто-то другой) могла внести такие изменения в
+ хранилище, которые трудно совместить с вашей рабочей копией
+ — особенно, если вы выполните <command>svn update</command>
+ впервые после нескольких недель изоляции.</para>
<!-- @ENGLISH {{{
@@ -267,11 +269,12 @@
collaborators. You'll see exactly how this works later
on.</para>
@ENGLISH }}} -->
- <para>Лучшим решением является создание вашей собственной ветки, или
- направления разработки, в хранилище. Это позволит вам часто сохранять
- наполовину поломанную работу не пересекаясь с другими, и кроме того,
- вы можете выборочно разделять информацию с другими соразработчиками.
- Дальше по тексту вы увидите как все это работает.</para>
+ <para>Наилучшим решением будет создание в хранилище вашей собственной
+ ветки, или направления разработки. Это позволит вам сохранять
+ наполовину поломанную работу сколь угодно часто, не пересекаясь
+ с другими, и кроме того, вы сможете выборочно делиться
+ информацией с другими коллегами.
+ Дальше вы увидите, как всё это работает.</para>
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.using.create">
@@ -302,22 +305,21 @@
<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>Есть два способа создания копии. Сначала мы покажем
- неудачный способ, просто для того, что бы прояснить основные моменты.
- Для начала, создается рабочая копия корневой директории проекта
+ <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>
@@ -335,8 +337,8 @@
working-copy paths to the <command>svn copy</command>
command:</para>
@ENGLISH }}} -->
- <para>Теперь создание копии заключается в простой передаче
- двух путей в пределах рабочей копии команде
+ <para>Теперь, чтобы создать копию, достаточно просто передать
+ два пути в пределах рабочей копии команде
<command>svn copy</command>:</para>
<screen>
@@ -362,20 +364,20 @@
than resending all of the working copy data over the
network:</para>
@ENGLISH }}} -->
- <para>В этом случае, команда <command>svn copy</command>
- рекурсивно копирует рабочую директорию <filename>trunk</filename>
- в новую рабочую директорию
+ <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>
+ <command>svn status</command> покажет, что новый каталог
+ запланирован для добавления в хранилище. Обратите внимание
+ на знак <quote>+</quote> после буквы А. Он означает, что
+ запланированное для добавления представляет собой какую-то
+ <emphasis>копию</emphasis>, а не что-то новое.
+ При следующей фиксации Subversion создаст в хранилище
+ каталог <filename>/calc/branches/my-calc-branch</filename>,
+ скопировав его из <filename>/calc/trunk</filename>
+ вместо того, чтобы повторно отправлять по сети
+ всю информацию рабочей копии:</para>
<screen>
$ svn commit -m "Creating a private branch of /calc/trunk."
@@ -388,9 +390,9 @@
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>
+ <para>А теперь покажем простой способ создания ветки, о котором мы
+ упоминали раньше: команда <command>svn copy</command> может
+ оперировать двумя URL-адресами напрямую.</para>
<screen>
$ svn copy http://svn.example.com/repos/calc/trunk \
@@ -419,17 +421,18 @@
all.</para>
@ENGLISH }}} -->
<para>В сущности, между этими двумя методами нет разницы. Оба варианта
- создают в правке 341 новую директорию и эта новая директория является
+ создают в правке 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>
+ 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">
@@ -478,34 +481,33 @@
<sidebar>
<title>Легкие копии</title>
- <para>Хранилище Subversion спроектировано особым образом.
- При копировании директории, нет необходимости задумываться о
+ <para>Хранилище Subversion устроено особым образом.
+ При копировании каталога нет необходимости задумываться о
большом увеличении размера хранилища — на самом деле
- Subversion никогда не дублирует информацию. Вместо этого,
- создается новая сущность директории, которая указывает на
- <emphasis>существующие</emphasis> дерево файлов. Если вы
+ Subversion никогда не дублирует информацию. Вместо этого
+ создается новая точка входа в каталог, которая указывает на
+ <emphasis>существующее</emphasis> дерево файлов. Если вы
пользователь Unix, это тот же подход, что используется
для жестких ссылок. То есть копия, так сказать, стала
- <quote>ленивой</quote>. Это значит, что если вы зафиксируете
- изменения одного файла из скопированной директории,
- то изменится только этот файл — остальные файлы
- будут продолжать существовать как ссылки на первоначальные файлы
- в первоначальной директории.</para>
+ <quote>ленивой</quote>. Если в скопированном каталоге
+ вы измените только один файл, при фиксации изменится только
+ он — остальные файлы продолжат существовать как
+ ссылки на исходные файлы в исходном каталоге.</para>
- <para>Вот почему часто в разговоре пользователей Subversion можно
+ <para>Вот почему в разговорах пользователей Subversion часто можно
услышать о <quote>легких копиях</quote>. Не имеет значения,
- насколько директория большая — для создания копии требуется
+ насколько велик каталог — создание копии займет
очень небольшой фиксированный промежуток времени. Фактически,
- на этой функции основана работа фиксаций в Subversion: каждая
+ на этом подходе основана работа фиксаций в Subversion: каждая
правка является <quote>легкой копией</quote> предыдущей правки,
- с несколькими элементами лениво измененными в ней. (Что бы прочитать
- больше об этом, посетите веб сайт Subversion и прочитайте в
- документах по архитектуре Subversion о методе <quote>всплывающих
+ с несколькими элементами, лениво измененными в ней. (Чтобы узнать
+ подробности, посетите веб-сайт Subversion и прочитайте в
+ документации по архитектуре Subversion о методе <quote>всплывающих
пузырьков</quote>.)</para>
- <para>Конечно, эти внутренние механизмы копирования и деления
- информации скрыты от пользователя, который видит просто
- копии файлов. Основное здесь, это то, что копии легкие
+ <para>Конечно, эти внутренние механизмы копирования и совместного
+ использования информации скрыты от пользователя, который видит
+ просто копии файлов. Главное здесь то, что копии — легкие
как по времени, так и по размеру. Делайте ветки так часто, как
вам необходимо.</para>
@@ -523,8 +525,8 @@
@ENGLISH }}} -->
<title>Работа с веткой</title>
- <para>После создания ветки проекта, можно создать новую рабочую копию
- для начала ее использования:</para>
+ <para>После создания ветки проекта можно загрузить новую рабочую копию
+ и приступить к работе с ней:</para>
<screen>
$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
@@ -547,16 +549,16 @@
<para>Let's pretend that a week goes by, and the following
commits happen:</para>
@ENGLISH }}} -->
- <para>В этой рабочей копии нет ничего особенного; она является
- просто отражением другой директории хранилища. Когда вы
- фиксируете изменения, то если Салли сделает обновление, она их
- даже не увидит. Ее рабочая копия является копией
- <filename>/calc/trunk</filename>. (Прочтите далее в этой главе
+ <para>В этой рабочей копии нет ничего особенного; это
+ просто зеркало другого каталога хранилища. Однако, если Салли
+ обновит свою рабочую копию, она не увидит там ваших изменений.
+ Рабочая копия Салли создана из каталога
+ <filename>/calc/trunk</filename>. (Смотрите далее в этой главе
раздел <xref linkend="svn.branchmerge.switchwc"/>: команда
<command>svn switch</command> является альтернативным способом
создания рабочей копии ветки.)</para>
- <para>Предположим, что прошла неделя и были сделаны следующие
+ <para>Предположим, что за неделю были сделаны следующие
фиксации:</para>
<!-- @ENGLISH {{{
@@ -583,17 +585,17 @@
<itemizedlist>
<listitem><para>Вы внесли изменения в
<filename>/calc/branches/my-calc-branch/button.c</filename>,
- с созданием правки 342.</para>
+ создав таким образом правку 342.</para>
</listitem>
<listitem><para>Вы внесли изменения в
<filename>/calc/branches/my-calc-branch/integer.c</filename>,
- с созданием правки 343.</para>
+ создав правку 343.</para>
</listitem>
<listitem><para>Салли внесла изменения в
- <filename>/calc/trunk/integer.c</filename>, с созданием
- правки 344.</para>
+ <filename>/calc/trunk/integer.c</filename>, создав
+ правку 344.</para>
</listitem>
</itemizedlist>
@@ -611,16 +613,16 @@
changes made to your copy of
<filename>integer.c</filename>:</para>
@ENGLISH }}} -->
- <para>Теперь есть два независимых направления разработки файла
- <filename>integer.c</filename>, которые показывает <xref
- linkend="svn.branchmerge.using.work.dia-1"/>.</para>
+ <para>Теперь у файла <filename>integer.c</filename>
+ есть два независимых направления разработки, что демонстрирует
+ <xref linkend="svn.branchmerge.using.work.dia-1"/>.</para>
<figure id="svn.branchmerge.using.work.dia-1">
<title>История ветвления для одного файла</title>
<graphic fileref="images/ch04dia4.png"/>
</figure>
- <para>Если посмотреть историю сделанных изменений для вашей копии
+ <para>Если посмотреть историю изменений, сделанных в вашей копии
<filename>integer.c</filename>, можно увидеть интересные
вещи:</para>
@@ -670,14 +672,14 @@
copied. Now look what happens when Sally runs the same
command on her copy of the file:</para>
@ENGLISH }}} -->
- <para>Обратите внимание на то, что Subversion прослеживает
- историю ветки <filename>integer.c</filename> во времени полностью,
+ <para>Обратите внимание на то, что Subversion полностью прослеживает
+ всю историю ветки <filename>integer.c</filename> во времени,
в том числе пересекая точку создания копии. Создание ветки
- показывается как событие в истории, потому что файл
- <filename>integer.c</filename> был неявно скопирован, при
- копировании всей директории <filename>/calc/trunk/</filename>.
- Теперь давайте посмотрим, что будет когда такую же команду Салли
- выполнит для своей копии файла:</para>
+ показано как событие в истории, потому что файл
+ <filename>integer.c</filename> был неявно скопирован при
+ копировании всего каталога <filename>/calc/trunk/</filename>.
+ Теперь давайте посмотрим, какой результат выдаст такая же
+ команда для Салли:</para>
<screen>
$ pwd
@@ -718,14 +720,14 @@
341, they used to be the same file. That's why you and Sally
both see the changes made in revisions 303 and 98.</para>
@ENGLISH }}} -->
- <para>Салли увидит свои собственные изменения правки 344, а ваши
- сделанные в правке 343 нет. Subversion позаботилась о том, что
- бы эти две фиксации затронули разные файлы, имеющие разное
- расположение в хранилище. Тем не менее, Subversion
- <emphasis>будет</emphasis> показывать то, что два файла имеют одну
- историю. До создания в правке 341 ветки (или копии) это был один файл.
- Поэтому и вы и Салли видите изменения сделанные в правке 303 и
- 98.</para>
+ <para>Салли увидит свои собственные изменения в правке 344,
+ а ваши, сделанные в правке 343 — нет. Subversion
+ позаботилась о том, чтобы эти две фиксации затронули разные
+ файлы, имеющие разное расположение в хранилище. Тем не менее,
+ Subversion <emphasis>будет</emphasis> показывать то, что два файла
+ имеют общую историю. До создания ветки-копии в правке 341 это был
+ один файл. Поэтому и вы, и Салли видите изменения, сделанные в
+ правках 303 и 98.</para>
</sect2>
@@ -759,25 +761,24 @@
@ENGLISH }}} -->
<title>Ключевые идеи, стоящие за ветками</title>
- <para>Два важных понятия, которые вы должны запомнить из этого
- раздела.</para>
+ <para>Из этого раздела вы должны запомнить две вещи.</para>
<orderedlist>
<listitem>
- <para>В отличие от других систем управления версиями,
- ветки в Subversion существуют в хранилище не в отдельном измерении,
- а как обычные <emphasis>нормальные директории файловой
- системы</emphasis>. Такие директории просто содержат дополнительную
+ <para>В отличие от многих других систем управления версиями,
+ в хранилище Subversion ветки существуют не в отдельном измерении,
+ а как <emphasis>обычные каталоги файловой системы</emphasis>.
+ Эти каталоги отличаются только тем, что несут дополнительную
информацию о своей истории.</para>
</listitem>
<listitem>
<para>Subversion не имеет такого понятия как ветка —
- есть только копии. При копировании директории результирующая
- директория становиться <quote>веткой</quote> только потому что
+ есть только копии. Копия каталога
+ становится <quote>веткой</quote> только потому, что
<emphasis>вы</emphasis> рассматриваете ее таким образом.
- Вы можете по-разному думать о директории, по разному ее трактовать,
- но для Subversion это просто обычная директория которая была
- создана копированием.</para>
+ Вы можете по-разному думать о каталоге, по разному его
+ трактовать, но для Subversion это не более чем обычный каталог,
+ созданный в результате копирования.</para>
</listitem>
</orderedlist>
@@ -806,16 +807,17 @@
@ENGLISH }}} -->
<title>Копирование изменений между ветками</title>
- <para>Сейчас вы и Салли работаете над параллельными ветками проекта:
- вы работаете над своей собственной веткой, а Салли работает над
- главной линией разработки (<firstterm>trunk</firstterm>).</para>
-
- <para>В проектах, имеющих большое количество участников, как правило
- большинство участников имеют рабочую копию главной линии разработки.
- Когда кому-то необходимо сделать долгосрочные изменения,
- которые возможно нарушат главную линию, стандартной процедурой
- является создать отдельную ветку и фиксировать изменения туда
- пока работа не будет полностью завершена.</para>
+ <para>Теперь вы и Салли работаете над параллельными ветками проекта:
+ вы — над своей собственной веткой, а Салли — над
+ главной линией разработки
+ (каталог <firstterm>trunk</firstterm>).</para>
+
+ <para>В проектах со значительным числом участников, как правило,
+ большинство работает в главной линии разработки.
+ Когда кому-то необходимо сделать изменения, которые займут
+ много времени и могут нарушить главную линию, стандартной практикой
+ является создание отдельной ветки и фиксация всех изменений в ней
+ — до тех пор, пока работа не будет полностью завершена.</para>
<!-- @ENGLISH {{{
<para>So, the good news is that you and Sally aren't interfering
@@ -833,22 +835,22 @@
completely finished with your branch, your entire set of branch
changes can be copied back into the trunk.</para>
@ENGLISH }}} -->
- <para>Положительным моментом является то, что вы и Салли не
- пересекаетесь друг с другом. Отрицательный момент в том, что
+ <para>Положительным моментом здесь является то, что вы и Салли не
+ пересекаетесь друг с другом. Но есть и минус —
вы можете разойтись <emphasis>слишком</emphasis> далеко друг
- относительно друга. Помните, что одной из проблем такой
- <quote>сходящейся к тупику</quote> стратегии является то,
- что к моменту, когда вы закончите работу со своей веткой
- может быть практически невозможно снова объединить ваши изменения
+ относительно друга. Помните, что одна из проблем такой
+ стратегии <quote>временной изоляции</quote> заключается в том,
+ что к моменту, когда вы завершите работу со своей веткой,
+ может оказаться практически невозможным объединить ее
с главной линией без огромного количества конфликтов.</para>
<para>Вместо этого вы и Салли можете продолжать делиться изменениями
по ходу работы. Вы можете решать вплоть до отдельного изменения,
- стоит ли им делиться; Subversion предоставляет возможность
+ стоит ли им делиться — Subversion предоставляет возможность
выборочного <quote>копирования</quote> изменений между ветками.
- А тогда, когда ваша ветка будет полностью закончена, полный набор
- изменений ветки может быть скопирован обратно в основную
- ветку.</para>
+ А тогда, когда вы полностью закончите работу со своей веткой,
+ вы можете скопировать обратно в основную ветку все изменения
+ полностью.</para>
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.copychanges.specific">
@@ -879,25 +881,26 @@
@ENGLISH }}} -->
<title>Копирование отдельных изменений</title>
- <para>В предыдущем пункте мы указали, что и вы и Салли, вместе,
- в разных ветках вносите изменения в <filename>integer.c</filename>.
- Если посмотреть на лог сообщение Салли для правки 344, вы увидите,
+ <para>В предыдущем разделе мы отметили, что и вы, и Салли,
+ одновременно, в разных ветках вносите изменения в файл
+ <filename>integer.c</filename>.
+ Если посмотреть на лог-сообщение Салли для правки 344, вы увидите,
что она исправила несколько орфографических ошибок. Конечно же,
- в вашей копии этого файла эти ошибки остались. Возможно, что
- ваши будущие изменения для этого файла коснутся областей которые
- содержат орфографические ошибки и таким образом вы получите несколько
- потенциальных конфликтов при последующем объединении вашей ветки.
- Поэтому, лучше получить изменения Салли сейчас,
- <emphasis>до</emphasis> того, как вы начнете вплотную работать в
- этих областях файла.</para>
+ в вашей копии этого файла эти ошибки остались. Не исключено, что
+ ваши будущие изменения этого файла коснутся областей,
+ содержащих эти орфографические ошибки, и таким образом вы получите
+ несколько потенциальных конфликтов при последующем объединении
+ вашей ветки. Поэтому лучше получить изменения от Салли сейчас,
+ <emphasis>до</emphasis> того, как вы начнете вплотную работать с
+ этой частью файла.</para>
<para>Настал момент воспользоваться командой <command>svn
merge</command>. Эта команда, оказывается, является очень близким
родственником команды <command>svn diff</command> (о которой вы
- читали <xref linkend="svn.tour"/>). Обе эти команды способны
- сравнивать любые два объекта в хранилище и показывать изменения.
+ читали в <xref linkend="svn.tour"/>). Обе команды способны
+ сравнивать любые два объекта в хранилище и показывать различия.
Например, вы можете попросить <command>svn diff</command> показать
- все изменения сделанные Салли в правке 344:</para>
+ все изменения, сделанные Салли в правке 344:</para>
<screen>
$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk
@@ -950,9 +953,9 @@
terminal, however, it applies them directly to your working
copy as <emphasis>local modifications</emphasis>:</para>
@ENGLISH }}} -->
- <para>Команда <command>svn merge</command> ведет себя практически
- полностью идентично. Но вместо вывода различий на терминал,
- применяет их к рабочей копии в виде <emphasis>локальных
+ <para>Команда <command>svn merge</command> ведет себя
+ практически идентично. Но вместо вывода различий на терминал
+ она применяет их к рабочей копии в виде <emphasis>локальных
изменений</emphasis>:</para>
<screen>
@@ -982,16 +985,16 @@
@ENGLISH }}} -->
<para>Вывод команды <command>svn merge</command> показывает, что
к вашей копии <filename>integer.c</filename> был применен патч.
- Теперь она содержит изменения Салли — изменения Салли были
+ Теперь она содержит изменения Салли — они были
<quote>скопированы</quote> из главной линии разработки в вашу
- рабочую копию, вашей личной ветки и теперь существуют в виде
+ рабочую копию, вашу собственную ветку, и теперь существуют в виде
локальных изменений. С этого момента вы можете просмотреть локальные
- изменения и убедиться в том, что они корректно работают.</para>
+ изменения и убедиться в том, что они корректны.</para>
- <para>По другому сценарию, возможно, что не все будет так хорошо
- и <filename>integer.c</filename> может оказаться в состоянии
- конфликта. Вам необходимо будет при помощи стандартной процедуры
- (см. <xref linkend="svn.tour"/>) решить конфликт, либо если вы
+ <para>Возможна ситуация, когда не все будет так хорошо
+ и <filename>integer.c</filename> окажется в состоянии
+ конфликта. Тогда вам будет необходимо разрешить конфликт
+ обычным путем (см. <xref linkend="svn.tour"/>), либо, если вы
придете к мнению, что объединение было плохой идеей, просто
отказаться от него, отменив локальные изменения командой
<command>svn revert</command>.</para>
@@ -1008,15 +1011,15 @@
message mentions that you're porting a specific change from
one branch to another. For example:</para>
@ENGLISH }}} -->
- <para>После просмотра результата объединения изменений, можно
- их как обычно зафиксировать (<command>svn commit</command>).
+ <para>Просмотрев результат объединения исправлений, его можно
+ зафиксировать как обычно (<command>svn commit</command>).
После этого изменения будут внесены в вашу ветку хранилища.
- В терминах контроля версий такую процедуру копирования
+ В терминологии управления версиями такую процедуру копирования
изменений между ветками обычно называют
<firstterm>портированием</firstterm> изменений.</para>
- <para>При фиксации локальных изменений, убедитесь, что в лог
- сообщении упоминается о портировании отдельных изменений
+ <para>При фиксации локальных изменений убедитесь, что в
+ лог-сообщении упоминается о портировании отдельных изменений
из одной ветки в другую. Например:</para>
<screen>
@@ -1040,16 +1043,16 @@
For example:</para>
@ENGLISH }}} -->
<para>Как вы увидите в последующих разделах, очень важно следовать
- подобному <quote>хорошему стилю</quote> организации работы.</para>
+ этой <quote>хорошей практике</quote>.</para>
<sidebar>
<title>Почему бы не использовать вместо этого патчи?</title>
- <para>Вопрос, который может крутиться у вас в голове, особенно
- если вы пользователь Unix: зачем вообще связываться с
- <command>svn merge</command>? Почему просто не использовать
+ <para>Зачем вообще связываться с <command>svn merge</command>?
+ Этот вопрос может крутиться у вас в голове, особенно
+ если вы пользователь Unix: Почему бы не использовать
команду операционной системы <command>patch</command> для
- выполнения этой работы? Например:</para>
+ выполнения той же работы? Например:</para>
<screen>
$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk > patchfile
@@ -1084,26 +1087,26 @@
changes in tree structure and properties by directly applying
them to your working copy.</para>
@ENGLISH }}} -->
- <para>Для этого конкретного случая, да, действительно разницы
- нет. Однако, <command>svn merge</command> имеет специфические
- функции благодаря которым превосходит программу
- <command>patch</command>.
- Формат файлов, используемый программой <command>patch</command>
- довольно таки ограниченный; он способен передавать только изменения
- содержимого файлов. Он не имеет способа для представления изменений
- <emphasis>дерева</emphasis> файлов, таких, как добавление, удаление
- или переименование файлов и директорий. Если скажем, в результате
- изменений Салли, добавилась новая директория то в выводе
- <command>svn diff</command> упоминания об этом не будет.
+ <para>Для этого конкретного случая, действительно, разницы
+ нет. Однако, <command>svn merge</command> имеет
+ специфические возможности, благодаря которым превосходит
+ программу <command>patch</command>.
+ Формат файлов, используемый программой <command>patch</command>,
+ является довольно ограниченным; он способен передавать только
+ изменения содержимого файлов. Он не позволяет описать изменения
+ <emphasis>дерева</emphasis> файлов, такие как добавление,
+ удаление или переименование файлов и каталогов. Если, скажем,
+ в результате исправлений Салли добавился новый каталог, в
+ выводе <command>svn diff</command> это упоминаться не будет.
Вывод <command>svn diff</command> представляет собой только
- ограниченный патч-формат, по этому некоторые понятия он просто не
- может передать. <footnote><para>В будущем, проект Subversion
+ ограниченный патч-формат, он просто не может передать
+ некоторые вещи. <footnote><para>В будущем проект Subversion
планирует использовать (или изобрести) расширенный формат
представления различий, который будет передавать изменения в
структуре дерева файлов и свойств.</para></footnote> Команда
<command>svn merge</command>, напротив, может передавать
- изменения в структуре файлов и свойств, непосредственно применяя
- их к рабочей копии.</para>
+ изменения в структуре файлов и свойств, непосредственно
+ применяя их к рабочей копии.</para>
</sidebar>
@@ -1131,23 +1134,23 @@
</orderedlist>
@ENGLISH }}} -->
<para>Небольшое предупреждение: несмотря на то, что <command>svn
- diff</command> и <command>svn merge</command> очень похожи в
- основе, в большинстве случаев они имеют разные правила записи.
+ diff</command> и <command>svn merge</command> по сути очень
+ похожи, во многих случаях они используют разный синтаксис.
Обязательно прочтите об этом в <xref linkend="svn.ref"/>, или
спросите у <command>svn help</command>. Например, <command>svn
merge</command> требует в качестве целевого объекта путь в
- рабочей копии, т. е. место, где ей нужно применить изменения
+ рабочей копии, то есть место, где ей нужно применить изменения
структуры файлов. Если целевой объект не указан, предполагается,
что делается попытка выполнить одну из следующих операций:</para>
<orderedlist>
<listitem>
- <para>Вы хотите объединить изменения директории с вашей текущей
- рабочей директорией.</para>
+ <para>объединение изменений каталога с вашим текущим
+ рабочим каталогом;</para>
</listitem>
<listitem>
- <para>Вы хотите объединить изменения в конкретном файле с
- файлом, имеющим то же имя в текущей рабочей директории.</para>
+ <para>объединение изменений в конкретном файле с
+ файлом, имеющим то же имя в текущем рабочем каталоге.</para>
</listitem>
</orderedlist>
@@ -1165,18 +1168,18 @@
directory of your working copy, you'll have to specify the
target directory to receive the changes:</para>
@ENGLISH }}} -->
- <para>Если вы объединяете директорию и не указываете целевой путь
+ <para>Если вы объединяете каталог и не указываете целевой путь,
<command>svn merge</command> предполагает первый из приведенных выше
- вариантов и попытается применить изменения к текущей директории.
- Если вы объединяете файл и такой файл (то есть файл с таким именем)
- существует в текущей рабочей директории, <command>svn merge</command>
+ вариантов и пытается применить изменения к текущему каталогу.
+ Если вы объединяете файл, и при этом файл с таким именем
+ есть в текущем рабочем каталоге, <command>svn merge</command>
подразумевает второй случай и пытается применить изменения
к локальному файлу с таким же именем.</para>
<para>Если вы хотите применить изменения к чему-то другому, вам
- нужно это указать. Например, если вы находитесь в родительской
- директории рабочей копии то вам нужно указать целевую директорию,
- получающую изменения:</para>
+ нужно это указать. Например, если вы находитесь в родительском
+ каталоге рабочей копии, то вам нужно указать целевой каталог,
+ получающий изменения:</para>
<screen>
$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
@@ -1214,23 +1217,24 @@
<title>Ключевые понятия, стоящие за слиянием</title>
<para>Вы увидели примеры использования <command>svn
- merge</command>, продолжим рассмотрение. Если вы чувствуете
- неуверенность в том как собственно работает слияние, то в этом
+ merge</command>, так что настала пора разобраться поглубже.
+ Если вы чувствуете неуверенность в том как, собственно,
+ работает слияние, то вы в этом
вы не одиноки. Многие пользователи (особенно те, для которых
управление версиями в новинку) поначалу путаются в правильности
записи этой команды и в том, как и когда эту функцию следует
- использовать. Отбросьте страх, на самом деле эта команда намного
- проще чем вы думаете! Очень просто понять механизм
- того, как именно ведет себя <command>svn merge</command>.</para>
+ использовать. Отбросьте страх — на самом деле эта команда
+ намного проще, чем вы думаете! Понять, как именно ведет себя
+ <command>svn merge</command>, очень просто.</para>
- <para>В замешательство приводит, главным образом
+ <para>В ступор вводит, главным образом,
<emphasis>название</emphasis> команды. Термин <quote>слияние</quote>
как бы указывает на то, что ветки соединяются вместе, или
происходит какое-то волшебное смешивание данных. На самом деле это
- не так. Лучшим названием для этой команды могло быть <command>svn
- diff-and-apply</command> потому что это все, что происходит:
- сравниваются два файловых дерева хранилища, а различия переносятся
- в рабочую копию.</para>
+ не так. Пожалуй, этой команде лучше бы подощло название <command>svn
+ diff-and-apply</command>, поскольку это всё, что в результате
+ происходит: сравниваются два файловых дерева хранилища, а
+ различия переносятся в рабочую копию.</para>
<!-- @ENGLISH {{{
<para>The command takes three arguments:</para>
More information about the svnbook-dev
mailing list