[svnbook commit] r3340 - trunk/src/ru/book
Imaged
noreply at red-bean.com
Tue Oct 28 16:27:29 CDT 2008
Author: Imaged
Date: Tue Oct 28 16:27:29 2008
New Revision: 3340
Log:
* ru/book/ch-branching-and-merging.xml: essential fixes of stylistics and spell checking
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 Oct 28 16:27:29 2008
@@ -61,7 +61,7 @@
<quote>адаптированном</quote> для них варианте, поскольку
работа каждого подразделения имеет свою специфику.</para>
- <para>Как вы поступите в такой ситуации? Очевидно, вы сделаете так:
+ <para>Как быть в такой ситуации? Скорее всего, вы
создадите вторую копию документа и начнёте отдельно сопровождать
обе копии. Когда какое-то из подразделений попросит вас
внести небольшие изменения, вы включите их либо в первую копию,
@@ -1214,11 +1214,11 @@
two repository trees are compared, and the differences are
applied to a working copy.</para>
@ENGLISH }}} -->
- <title>Ключевые понятия, стоящие за слиянием</title>
+ <title>Ключевые идеи, стоящие за слиянием</title>
- <para>Вы увидели примеры использования <command>svn
- merge</command>, так что настала пора разобраться поглубже.
- Если вы чувствуете неуверенность в том как, собственно,
+ <para>Теперь, после знакомства с примерами использования <command>svn
+ merge</command>, настала пора разобраться в них поглубже.
+ Если вы чувствуете неуверенность в том как, собственно,
работает слияние, то вы в этом
вы не одиноки. Многие пользователи (особенно те, для которых
управление версиями в новинку) поначалу путаются в правильности
@@ -1267,7 +1267,7 @@
называемое <firstterm>правой частью</firstterm> при
сравнении),</para></listitem>
- <listitem><para>Рабочую копию для применения отличий,
+ <listitem><para>Рабочую копию, к которой отличия применяются
в виде локальных изменений (как правило, называемую
<firstterm>целью</firstterm> слияния).</para></listitem>
@@ -1288,19 +1288,19 @@
specify the three necessary arguments rather flexibly. Here
are some examples:</para>
@ENGLISH }}} -->
- <para>Когда эти три аргумента указаны, сравниваются два дерева
- и результирующие различия применяются к целевой рабочей копии
- в виде локальных изменений. После того, как команда выполнена,
- результат не будет отличаться он того как если бы вы вручную
- редактировали файлы или многократно выполняли команды
- <command>svn add</command> или <command>svn delete</command>
- самостоятельно. Если результат вас устраивает, его можно
+ <para>Когда эти три аргумента указаны, производится сравнение
+ двух деревьев, а полученные различия применяются к целевой
+ рабочей копии в виде локальных изменений. После выполнения
+ этой команды результат будет так же, как в случае, если бы вы
+ вручную редактировали файлы или многократно выполняли команды
+ <command>svn add</command> или <command>svn delete</command>.
+ Если результат вас устраивает, его можно
зафиксировать. Если результат вас не устраивает, просто
отмените (<command>svn revert</command>) все сделанные
изменения.</para>
- <para>Правила записи <command>svn merge</command> позволяют
- указывать три необходимых аргумента довольно гибко. Вот
+ <para>Синтаксис <command>svn merge</command> позволяет
+ указывать эти три аргумента довольно гибко. Вот
несколько примеров:</para>
<screen>
@@ -1322,14 +1322,14 @@
how the working-copy argument is optional; if omitted, it
defaults to the current directory.</para>
@ENGLISH }}} -->
- <para>В первом примере записи все три аргумента явно указаны,
- указываются деревья, в форме <emphasis>URL at REV</emphasis> и
- указывается целевая рабочая копия. Второй пример записи может
- использоваться для краткости записи, в ситуациях, когда
+ <para>В первом варианте все три аргумента указаны явно —
+ каждое дерево задано в форме <emphasis>URL at REV</emphasis> и
+ указана целевая рабочая копия. Второй вариант может
+ использоваться для краткости записи в ситуациях, когда
сравниваются две разных правки по одному и тому же URL.
- Последний пример демонстрирует возможность не указывать целевую
- рабочую копию, при этом по умолчанию используется текущая
- директория.</para>
+ Последний вариант демонстрирует возможность не указывать целевую
+ рабочую копию, при этом по умолчанию используется текущий
+ каталог.</para>
</sect2>
@@ -1360,12 +1360,12 @@
на практике могут возникнуть трудности. Проблема заключается
в том, что при многократном объединении изменений одной
ветки с другой можно непреднамеренно сделать объединение одних
- и тех же изменений <emphasis>дважды</emphasis>. Иногда,
- когда это случается, проблем это не вызывает. При внесении
- изменений в файл, как правило Subversion предупреждает
- о том что файл уже содержит изменения и в этом случае не
- выполняет никаких действий. Однако если уже присутствующие
- изменения были модифицированы, то возникнет конфликт.</para>
+ и тех же изменений <emphasis>дважды</emphasis>. Иногда
+ это не вызывает проблем. При применении изменений к файлу
+ Subversion, как правило, предупреждает о том, что файл
+ уже содержит изменения и в этом случае не
+ выполняет никаких действий. Однако, если уже присутствующие
+ изменения были модифицированы, возникнет конфликт.</para>
<!-- @ENGLISH {{{
<para>Ideally, your version control system should prevent the
@@ -1382,16 +1382,16 @@
running <command>svn merge</command>, or from just
hand-editing the files.</para>
@ENGLISH }}} -->
- <para>В идеале, система управления версиями должна предотвращать
+ <para>В идеале система управления версиями должна предотвращать
повторное применение изменений к ветке. Она должна автоматически
фиксировать, какие изменения уже были получены и иметь возможность
- перечислить их вам. Должна использовать эту информацию для того,
- чтобы, насколько возможно, помочь автоматизировать
+ перечислить их вам. Она должна использовать эту информацию
+ для того, чтобы, насколько возможно, помочь автоматизировать
слияние.</para>
<para>К сожалению, Subversion не такая система. Как и
CVS, Subversion пока не сохраняет никакой информации об
- операциях объединения. При фиксации локальных изменений хранилище
+ операциях слияния. При фиксации локальных изменений хранилище
понятия не имеет, являются ли эти изменения результатом
выполнения команды <command>svn merge</command> или результатом
обычного ручного редактирования файлов.</para>
@@ -1413,20 +1413,20 @@
<para>In the next section, we'll show some examples of this
technique in action.</para>
@ENGLISH }}} -->
- <para>Что это означает для вас, как пользователя? Это означает,
+ <para>Что это означает для вас как пользователя? Это означает,
что до того момента, пока у Subversion не появится этой функции,
вам придется контролировать слияние информации самостоятельно.
Лучшим местом для этого является лог-сообщение. Как было
- показано в предыдущих примерах, рекомендуется, что бы в
+ показано в предыдущих примерах, рекомендуется, чтобы в
лог-сообщении был указан конкретный номер правки (или диапазон
- правок) которые были слиты в вашу ветку. После этого, для того,
- что бы просмотреть какие изменения ваша ветка уже содержит,
- вы можете запустить команду <command>svn log</command>. Это
- позволит быть аккуратнее при выполнении команды <command>svn
- merge</command>, что бы не пересечься с уже портированными
- изменениями.</para>
+ правок), которые были слиты в вашу ветку. В этом случае вы
+ сможете впоследствии просмотреть, какие изменения уже содержит
+ ваша ветка, запусти команду <command>svn log</command>. Это
+ позволит быть осторожнее при последующих запусках команды
+ <command>svn merge</command> и избежать пересечения с уже
+ портированными изменениями.</para>
- <para>В следующем разделе мы на примерах рассмотрим эту технику
+ <para>В следующем разделе мы на примерах рассмотрим эту методику
в действии.</para>
</sect3>
@@ -1446,19 +1446,19 @@
<command>svn revert</command> is no longer an option. The
two sets of changes may be impossible to separate.</para>
@ENGLISH }}} -->
- <title>Предварительные просмотр при объединении</title>
+ <title>Предварительный просмотр результатов слияния</title>
- <para>Учитывая, что результатом слияния являются локальные
- модификации, такая операция не является опасной. Если
- в начале, при выполнении объединения вы ошиблись, просто
- отмените изменения (<command>svn revert</command>) и
- попробуйте еще раз.</para>
+ <para>Поскольку результатом слияния являются локальные
+ изменения, такая операция не является опасной. Допустив
+ при слиянии ошибку, можно просто
+ отменить изменения (<command>svn revert</command>) и
+ попробовать еще раз.</para>
<para>Однако, возможна ситуация, когда рабочая копия уже
содержит локальные изменения. Изменения, примененные при
- слиянии будут смешаны с уже существующими и
- <command>svn revert</command> запустить будет нельзя.
- Если нельзя будет разделить два набора изменений.</para>
+ слиянии, будут смешаны с уже существующими, и запуск
+ <command>svn revert</command> нас больше не устроит.
+ Разделить два множества изменений будет невозможно.</para>
<!-- @ENGLISH {{{
<para>In cases like this, people take comfort in being able to
@@ -1470,13 +1470,13 @@
<option>-ﳢ-dry-run</option> option to the merge
command:</para>
@ENGLISH }}} -->
- <para>В такой ситуации лучше будет попробовать спрогнозировать
- или проверить объединения до того, как они произойдут.
- Самым простым вариантом является запуск <command>svn diff</command>
- с теми же аргументами, что и для <command>svn merge</command>,
- это мы уже показывали в первом примере объединения. Другим
- вариантом предпросмотра является передача команде объединения
- опции <option>--dry-run</option>:</para>
+ <para>В такой ситуации лучше попробовать спрогнозировать
+ или проверить результат слияния до того, как оно произойдет.
+ Проще всего запустить для этого <command>svn diff</command>
+ с теми же аргументами, что и для <command>svn merge</command>.
+ Мы уже показывали это в первом примере объединения. Другим
+ способом предварительного просмотра может служить вызов
+ команды слияния с опцией <option>--dry-run</option>:</para>
<screen>
$ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
@@ -1495,13 +1495,13 @@
times when running <command>svn diff</command> gives too
much detail.</para>
@ENGLISH }}} -->
- <para>Опция <option>--dry-run</option> не вносит локальные
- изменения в рабочую копию. Показываются только коды
- статуса которые <emphasis>будут</emphasis> выведены
- при настоящем объединении. Это полезно для получения
- <quote>обобщенной</quote> информации об объединении
- для тех случаев, когда запуск <command>svn diff</command>
- выдает слишком детальную информацию.</para>
+ <para>Опция <option>--dry-run</option> позволяет не применять
+ локальные изменения к рабочей копии. Она только показывает
+ статусы, которые <emphasis>имели бы</emphasis> файлы
+ при реальном объединении. Это полезно для получения
+ <quote>сводной</quote> информации о потенциальном слиянии
+ в тех случаях, когда запуск <command>svn diff</command>
+ выдает слишком много подробностей.</para>
</sect3>
@@ -1527,20 +1527,21 @@
delta is guaranteed to correctly convert your working copy
into the right-hand tree.</para>
@ENGLISH }}} -->
- <title>Конфликты при объединении</title>
+ <title>Конфликты при слиянии</title>
- <para>Так же как и команда <command>svn update</command>,
+ <para>Так же как и <command>svn update</command>, команда
<command>svn merge</command> внедряет изменения в
- рабочую копию. А следовательно тоже может создавать
- конфликты. Однако конфликты, создаваемые <command>svn
- merge</command> иногда отличаются и эти отличия
- рассмотрены в этом разделе.</para>
+ рабочую копию. Следовательно, она тоже может создавать
+ конфликты. Однако конфликты, порождаемые <command>svn
+ merge</command>, имеют определенные отличия, и поэтому
+ мы их сейчас рассмотрим подробнее.</para>
- <para>В начале будем считать, что рабочая копия не имеет
+ <para>Вначале предположим, что рабочая копия не имеет
локальных изменений. При обновлении (<command>svn
- update</command>) до конкретной правки, изменения, отправляемые
- сервером, будут всегда <quote>без проблем</quote> внедрятся
- в рабочую копию. Сервер создает дельту сравнивая два дерева:
+ update</command>) рабочей копии до конкретной правки
+ отправляемые сервером изменения будут всегда <quote>без
+ проблем</quote> внедряться
+ в рабочую копию. Сервер создает дельту, сравнивая два дерева:
виртуальный снимок рабочей копии и дерево файлов, которое
вас интересует. Учитывая то, что левая часть сравнения
полностью эквивалентна тому, что вы уже имеете, дельта
@@ -1561,17 +1562,17 @@
<quote>failed hunks</quote>, <command>svn merge</command>
will complain about <quote>skipped targets</quote>:</para>
@ENGLISH }}} -->
- <para>Однако <command>svn merge</command> не может этого
- гарантировать и может вести себя более хаотично:
+ <para>Однако <command>svn merge</command> не дает такой
+ гарантии, и может вести себя более непредсказуемо:
пользователь может запросить сервер сравнить
<emphasis>любые</emphasis> два дерева файлов, даже такие,
которые не имеют отношения к рабочей копии! Из этого
- следует большое количество потенциальных человеческих
- ошибок. Пользователи иногда будут сравнивать два
- ошибочных дерева создавая дельту которая не
+ следует множество потенциальных человеческих
+ ошибок. Иногда пользователи будут сравнивать два
+ ошибочных дерева, создавая дельту, которая не
сможет правильно внедриться. <command>svn
- merge</command> будет пытаться внедрить по возможности
- больше различий, но иногда это будет невозможно.
+ merge</command> будет пытаться внедрить различия
+ по максимуму, но иногда это будет невозможно.
Так же как команда <command>patch</command> в Unix
иногда жалуется на <quote>неудачные попытки</quote>
объединения, <command>svn merge</command> будет
@@ -1618,22 +1619,22 @@
дельту для того, чтобы изменить содержимое файла, однако в
рабочей копии файл отсутствует. В любом случае сообщение
<quote>skipped</quote> означает, что скорее всего пользователь
- ошибся при указании деревьев для сравнения; классическая ошибка
- оператора. Если это произошло, то проще всего рекурсивно
- отменить все изменения, сделанные при слиянии (<command>svn
- revert --recursive</command>), сразу же после этого удалить
- все неверсионированные файлы и директории и повторно
- запустить <command>svn merge</command> с другими
- параметрами.</para>
+ ошибся при указании деревьев для сравнения — то есть это
+ классическая ошибка оператора. Если это так, проще
+ всего рекурсивно отменить все изменения, сделанные при слиянии
+ (<command>svn revert --recursive</command>), сразу же после
+ этого удалить все неверсионированные файлы и каталоги и
+ повторно запустить <command>svn merge</command> с
+ другими параметрами.</para>
<para>Обратите внимание на то, что в предыдущем примере
в файле <filename>glorb.h</filename> возник конфликт.
- Ранее мы договорились, что рабочая копия не имеет
- локальных изменений: откуда же взялся конфликт?
- Опять же, так как пользователь мог запустить <command>svn
+ Откуда же он мог взяться, если ранее мы договорились,
+ что рабочая копия не имеет локальных изменений?
+ Опять же, пользователь мог запустить <command>svn
merge</command> для выделения и применения к рабочей копии
- какой то старой дельты, в результате, такая дельта может
- содержать изменения, которые не смогут внедриться в рабочий
+ какой то старой дельты. В результате такая дельта может
+ содержать изменения, которые нельзя внедрить в рабочий
файл без появления проблем, даже если он не имеет локальных
изменений.</para>
@@ -1657,24 +1658,24 @@
update versus ones that happened as a result of a
merge.</para>
@ENGLISH }}} -->
- <para>Еще одно небольшое отличием между <command>svn
+ <para>Еще одно небольшое отличие между <command>svn
update</command> и <command>svn merge</command> заключается
- в названиях файлов, создаваемых при возникновении конфликта.
+ в названиях файлов, создаваемых при конфликтах.
В разделе <xref linkend="svn.tour.cycle.resolve"/> мы
говорили о том, что при обновлении создаются файлы с
названиями <filename>filename.mine</filename>,
- <filename>filename.rOLDREV</filename>, и
+ <filename>filename.rOLDREV</filename> и
<filename>filename.rNEWREV</filename>. А <command>svn
merge</command> в конфликтной ситуации создает три файла
с названиями <filename>filename.working</filename>,
<filename>filename.left</filename> и
- <filename>filename.right</filename>. Здесь, термины
- <quote>left</quote> и <quote>right</quote> указывают
+ <filename>filename.right</filename>. Термины
+ <quote>left</quote> и <quote>right</quote> указывают здесь
на две стороны сравнения, то есть на используемые при
сравнении деревья. Это разделение используемых названий
- поможет вам отличать конфликты возникшие в результате
- обновления от конфликтов, возникших в результате
- объединения.</para>
+ поможет вам отличать конфликты, возникшие в результате
+ обновления, от конфликтов, возникших в результате
+ слияния.</para>
</sect3>
@@ -1704,23 +1705,23 @@
@ENGLISH }}} -->
<title>Учитывать или игнорировать происхождение</title>
- <para>При общении разработчиков, использующих Subversion
- очень часто можно услышать упоминание термина
+ <para>Общаясь с разработчиками, использующими Subversion,
+ очень часто можно услышать термин
<firstterm>происхождение</firstterm>. Это слово используется
для описания отношений между двумя объектами хранилища:
- если между ними есть связь, тогда говорят, что один объект
- является предком другого.</para>
+ если между ними есть связь, то говорят, что один объект
+ происходит от другого.</para>
- <para>Например, предположим, что фиксируется правка 100,
- в которой содержатся изменения файла <filename>foo.c</filename>.
+ <para>Предположим, что фиксируется правка 100,
+ в которой изменяется файл <filename>foo.c</filename>.
В этом случае файл <filename>foo.c at 99</filename> является предком
файла <filename>foo.c at 100</filename>. С другой стороны, можно
допустить, что в правке 101 вы фиксируете удаление
<filename>foo.c</filename>, а затем в правке 102 добавляете
- новый файл с таким же именем. В таком случае файлы
- <filename>foo.c at 99</filename> и <filename>foo.c at 102</filename>
- могут выглядеть так, как будто они имеют друг к другу отношение
- (у них одинаковый путь), однако на самом деле являются
+ новый файл с таким же именем. В таком случае может показаться,
+ что файлы <filename>foo.c at 99</filename> и <filename>foo.c at 102</filename>
+ имеют отношение друг к другу (у них одинаковый путь),
+ однако на самом деле они являются
полностью независимыми объектами хранилища. Они не имеют
ни общей истории, ни общих <quote>предков</quote>.</para>
@@ -1738,10 +1739,10 @@
delete the old file, then add the new file; the output would
indicate a deletion followed by an add:</para>
@ENGLISH }}} -->
- <para>Мы обращаем на это ваше внимание, для того, чтобы
- указать на важные отличия между <command>svn diff</command>
+ <para>Мы обращаем на это ваше внимание, чтобы
+ указать на важные различия между <command>svn diff</command>
и <command>svn merge</command>. Первая команда игнорирует
- происхождение, в то время, как вторая его учитывает.
+ происхождение, в то время как вторая его учитывает.
Например, если попросить <command>svn diff</command> сравнить
правки 99 и 102 файла <filename>foo.c</filename> вы увидите
построчное сравнение; команда <literal>diff</literal> слепо сравнивает
@@ -1749,7 +1750,7 @@
сравнить те же объекты, то Subversion предупредит вас о том, что
они не связаны друг с другом и сначала попытается удалить
старый файл, а затем добавить новый; вывод команды покажет
- удаление с последующим добавлением:</para>
+ удаление с последующим добавлением:</para>
<screen>
D foo.c
@@ -1779,26 +1780,26 @@
<command>svn diff</command> to behave like the
<literal>merge</literal> command.)</para>
@ENGLISH }}} -->
- <para>В большинстве случаев при объединении сравниваются
+ <para>В большинстве случаев при слиянии сравниваются
деревья, имеющие родственную связь и по умолчанию
<command>svn merge</command> рассчитывает на это. Однако
- иногда, вам будет нужно, что бы команда <literal>merge</literal>
- сравнила два не связанных дерева файлов. Например, у вас может быть
- два импортированных дерева содержащих исходный код
- релизов программных проектов от сторонних поставщиков
+ иногда вам будет нужно, чтобы команда <literal>merge</literal>
+ сравнила два независимых дерева файлов. Например, вы могли
+ импортировать два дерева, содержащие исходный код
+ релизов программных проектов сторонних поставщиков
(см. <xref linkend="svn.advanced.vendorbr"/>). Если попросить
<command>svn merge</command> сравнить два эти дерева,
вы увидите, что первое дерево будет полностью удалено,
а затем будет полностью добавлено второе!</para>
- <para>В подобных ситуациях вам нужно, чтобы команда
- <command>svn merge</command> выполняла сравнение основанное
- только на пути, без учета любых отношений между файлами
- и директориями. Добавьте опцию <option>--ignore-ancestry</option>
- при записи команды объединения, после чего эта команда будет
- вести себя также как <command>svn diff</command>. (И наоборот,
- опция <option>--notice-ancestry</option> будет заставлять
- <command>svn diff</command> вести себя как команда
+ <para>В подобных ситуациях нужно, чтобы команда
+ <command>svn merge</command> выполняла сравнение, учитывая только
+ пути, и не обращала внимание на отношения между файлами
+ и каталогами. Добавьте опцию <option>--ignore-ancestry</option>
+ при запуске команды слияния, после чего она будет
+ вести себя аналогично <command>svn diff</command>. (И наоборот,
+ опция <option>--notice-ancestry</option> заставит
+ <command>svn diff</command> работать подобно команде
<literal>merge</literal>.)</para>
</sect3>
@@ -1819,11 +1820,11 @@
merge</command>, and this section describes the most common ones
you're likely to run into.</para>
@ENGLISH }}} -->
- <title>Типовые примеры использования</title>
+ <title>Типовые примеры</title>
- <para>Для ветвления и команды <command>svn merge</command>
- существует множество применений, в этом раздели описаны наиболее
- типичные из тех с которыми вы можете столкнуться.</para>
+ <para>Ветвлением и слиянием можно пользоваться по-разному.
+ В этом разделе описываются наиболее типичные примеры,
+ с которыми вам придется иметь дело.</para>
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.commonuses.wholebr">
@@ -1848,21 +1849,21 @@
@ENGLISH }}} -->
<title>Полное объединение двух веток</title>
- <para>Что бы завершить наш текущий пример, заглянем немного
- в перед. Предположим, прошло несколько дней и как в главную
- линию разработки так и вашу личную ветку было внесено множество
- изменений. Допустим, что работу над своей веткой вы завершили;
- добавление функциональности или исправление ошибок наконец
- закончено и теперь вы хотите объединить все изменения из своей
+ <para>Чтобы закончить с последним примером, заглянем немного
+ вперед. Предположим, что прошло несколько дней. И в главную
+ линию разработки, и вашу личную ветку за это время было внесено
+ множество изменений. Допустим, что работу над своей веткой вы
+ завершили. Новый функционал добавлен, ошибки исправлены,
+ и теперь вы хотите объединить все изменения из своей
ветки с главной линией разработки.</para>
- <para>Как же в этом случае нужно использовать <command>svn
- merge</command>? Помните о том, что эта команда сравнивает
- два дерева и применяет различия к рабочей копии. Поэтому,
- для того, что бы было к чему применять изменения, необходимо
+ <para>Как применить в этом случае <command>svn merge</command>?
+ Помните о том, что эта команда сравнивает
+ два дерева и применяет различия к рабочей копии. Следовательно,
+ для того, чтобы было к чему применять изменения, необходимо
иметь рабочую копию главной линии разработки. Будем считать,
- что-либо у вас под рукой имеется такая (полностью обновленная)
- копия, либо вы только что создали новую рабочую копию
+ что такая, полностью обновленная копия у вас либо уже есть,
+ либо вы ее только что создали в каталоге
<filename>/calc/trunk</filename>.</para>
<!-- @ENGLISH {{{
@@ -1888,27 +1889,27 @@
branch directory, and apply those differences to a working
copy of the trunk.</para>
@ENGLISH }}} -->
- <para>А какие именно два дерева должны сравниваться? На первый
- взгляд ответ очевиден: сравнивать последнее дерево главной
+ <para>Но какие именно два дерева нужно сравнивать? На первый
+ взгляд ответ очевиден: нужно сравнить последнее дерево главной
линии разработки с последним деревом вашей ветки. Однако
- будьте осторожны — такое предположение является
- <emphasis>ошибочным</emphasis>, многие новые пользователи
- ошибаются подобным образом! Учитывая то, что <command>svn
- merge</command> работает так же как <command>svn diff</command>,
- сравнение последние версии главной линии разработки и вашей ветки
- покажет изменения сделанные <emphasis>не</emphasis> только в вашей
- ветке. Такое сравнение покажет слишком много изменений: будут
- показано не только то, что добавлялось в вашей ветке,
+ такое предположение будет <emphasis>ошибочным</emphasis>.
+ Это типичная ошибка большинства новичков!
+ Поскольку <command>svn merge</command> работает так же как и
+ <command>svn diff</command>,
+ сравнение последней версии главной линии разработки и вашей ветки
+ покажет изменения, сделанные <emphasis>не</emphasis> только в вашей
+ ветке. Такое сравнение покажет слишком много изменений. Оно выведет
+ не только то, что добавлялось в вашей ветке,
но и то, что <emphasis>удалялось</emphasis> в главной линии
разработки и не удалялось в вашей ветке.</para>
- <para>Для выделения только тех изменений, которые были сделаны
+ <para>Чтобы выделить только те изменения, которые были сделаны
в вашей ветке, нужно сравнивать начальное и конечное состояния
- ветки. Воспользовавшись <command>svn log</command> для ветки,
- можно узнать, что она была создана в правке 341. А для определения
+ этой ветки. Посмотрев <command>svn log</command>,
+ можно узнать, что ветка была создана в правке 341. В качестве
конечного состояния ветки можно просто использовать правку
<literal>HEAD</literal>. Это значит, что вам нужно сравнить
- правки 341 и <literal>HEAD</literal> директории с веткой и применить
+ правки 341 и <literal>HEAD</literal> каталога с веткой и применить
различия к рабочей копии главной линии разработки.</para>
<!-- @ENGLISH {{{
@@ -1927,16 +1928,16 @@
<para>So in our continuing example,</para>
@ENGLISH }}} -->
<tip>
- <para>Удобно для определения правки, в которой ветка была создана
- (<quote>базовой</quote> правки ветки) использовать параметр
- <option>--stop-on-copy</option> при запуске <command>svn
- log</command>. При обычном запуске, эта команда показывает
- все изменения сделанные в ветке, включая те, которые были
- сделаны до создания ветки. Поэтому, при таком запуске
- вы увидите и историю главной линии разработки. Параметр
- <option>--stop-on-copy</option> остановит вывод лог сообщений
- как только <command>svn log</command> определит, что
- целевой объект был скопирован или переименован.</para>
+ <para>Для определения правки, в которой была создана ветка
+ (<quote>базовой</quote> правки ветки), удобно использовать
+ параметр <option>--stop-on-copy</option> команды <command>svn
+ log</command>. Обычно эта команда показывает все изменения,
+ сделанные в ветке, включая те, которые были
+ сделаны до создания ветки. Поэтому вы будете видеть и историю
+ главной линии разработки. Параметр
+ <option>--stop-on-copy</option> остановит вывод лог-сообщений,
+ как только <command>svn log</command> обнаружит
+ факт копирования или переименования целевого объекта.</para>
<screen>
$ svn log --verbose --stop-on-copy \
@@ -1956,16 +1957,15 @@
was created by copying.</para>
</tip>
@ENGLISH }}} -->
- <para>Как и ожидалось, последняя правка выведенная этой командой
- будет правка, в которой директория
- <filename>my-calc-branch</filename> была создана
- путем копированием.</para>
+ <para>Как и ожидалось, последней строчкой эта команда
+ выведет ту правку, в которой в результате копирования был
+ создан каталог <filename>my-calc-branch</filename>.</para>
</tip>
<!-- @ENGLISH {{{
<para>Here's the final merging procedure, then:</para>
@ENGLISH }}} -->
- <para>Вот так выглядит завершение объединения:</para>
+ <para>Теперь мы можем завершить объединение веток:</para>
<screen>
$ cd calc/trunk
@@ -2013,27 +2013,27 @@
trunk, and look for a log message about the last time you
merged from the branch:</para>
@ENGLISH }}} -->
- <para>Еще раз обратите внимание, на то, что в лог сообщении
+ <para>Еще раз обратите внимание на то, что в лог-сообщении
фиксации очень точно указан диапазон правок, которые были
объединены с главной линией разработки. Никогда не забывайте
этого делать, потому что это очень важная информация, которая
понадобиться вам позже.</para>
- <para>Например, предположим, что на следующей неделе вы решите
- продолжить работу над веткой, для завершения расширения
- функциональности или исправления ошибки. После этого, правка
- <literal>HEAD</literal> хранилища будет имеет номер 480 и вы готовы
- выполнить еще одно объединение своей личной копии с главной линией
+ <para>Предположим, что на следующей неделе вы решили
+ продолжить работу над своей веткой, чтобы доработать новый
+ функционал или исправить еще несколько ошибок. Теперь правка
+ <literal>HEAD</literal> хранилища имеет номер 480, и вы готовы
+ еще раз объединить свою личную копию с главной линией
разработки. Однако, как уже было сказано в разделе
- <xref linkend= "svn.branchmerge.copychanges.bestprac"/>, нет
- необходимости объединять изменения которые уже были объединены
- раньше; нужно объединить только <quote>новые</quote> изменения,
- появившиеся с момента последнего объединения. Сложность в том,
- что бы выделить эти новые изменения.</para>
-
- <para>Первым шагом является запуск <command>svn log</command>
- для главной линии разработки, для того, что бы увидеть
- сообщение о времени последнего объединения с веткой:</para>
+ <xref linkend= "svn.branchmerge.copychanges.bestprac"/>, ранее
+ объединенные изменения не стоит объединять повторно.
+ Объединению подлежат только <quote>новые</quote> изменения,
+ появившиеся с момента последнего объединения. Сложность заключается
+ в том, чтобы выделить эти новые изменения.</para>
+
+ <para>Первым шагом будет запуск <command>svn log</command>
+ для главной линии разработки, в результате чего мы узнаем
+ время последнего объединения с веткой:</para>
<screen>
$ cd calc/trunk
@@ -2054,11 +2054,11 @@
branch changes after that—by comparing revisions 406 and
<literal>HEAD</literal>.</para>
@ENGLISH }}} -->
- <para>Ага! Так как все изменения в ветке, которые делались между
- правками 341 и 405 уже были объединены с главной линией разработки
- в правке 406, то теперь вы знаете, что необходимо брать только те
- изменения ветки, которые были выполнены после этого —
- сравнивая правки 406 и <literal>HEAD</literal>.</para>
+ <para>Ага! Все изменения ветки, сделанные между
+ правками 341 и 405, уже были объединены с главной линией разработки
+ в правке 406. Поэтому сейчас нам нужно взять только
+ изменения, выполненные после этого. Для этого мы будем сравнивать
+ правки 406 и <literal>HEAD</literal>.</para>
<screen>
$ cd calc/trunk
@@ -2088,10 +2088,10 @@
merges.</para>
@ENGLISH }}} -->
<para>Теперь главная линия разработки полностью содержит вторую
- волну изменений, сделанных в ветке. С этого момента можно
+ волну изменений, сделанных в ветке. Теперь можно
либо удалить ветку (об этом мы поговорим позже), либо
- продолжать работать над веткой, с последующим объединением
- изменений.</para>
+ продолжить работу над ней, периодически повторяя при этом
+ процедуру объединения.</para>
</sect2>
@@ -2114,17 +2114,16 @@
@ENGLISH }}} -->
<title>Отмена изменений</title>
- <para>Еще одним типичным применением для <command>svn
- merge</command> является откат изменений, которые уже были
- зафиксированы. Предположим вы спокойно работаете в рабочей
- копии <filename>/calc/trunk</filename> и выясняете, что
- изменения сделанные в правке 303, которые изменили
- <filename>integer.c</filename>, полностью ошибочны. Вы можете
+ <para>Еще одной типичной задачей для <command>svn
+ merge</command> является откат ранее сделанных изменений.
+ Предположим, работая в копии <filename>/calc/trunk</filename>,
+ вы вдруг выясняете, что изменения файла <filename>integer.c</filename>,
+ сделанные в правке 303, были совершенно ошибочными. Вы можете
воспользоваться командой <command>svn merge</command> для
<quote>отмены</quote> изменений в своей рабочей копии,
после чего зафиксировать локальные изменения в хранилище.
- Все, что нужно сделать, это указать
- <emphasis>обратные</emphasis> отличия:</para>
+ Для этого нужно всего лишь указать различия в
+ <emphasis>обратном порядке</emphasis>:</para>
<screen>
$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
@@ -2155,13 +2154,13 @@
changeset #303 to our working copy
<emphasis>backwards</emphasis>.</para>
@ENGLISH }}} -->
- <para>Одним из взглядов на правку хранилища является представление
- ее в виде сгруппированных изменений (некоторые системы управления
- версиями называют это <firstterm>набором изменений</firstterm>).
- Используя параметр <option>-r</option> можно попросить
+ <para>Правку хранилища можно рассматривать как группу изменений
+ (некоторые системы управления версиями называют
+ это <firstterm>набором изменений</firstterm>).
+ Используя параметр <option>-r</option>, можно попросить
<command>svn merge</command> применить к рабочей копии набор
- изменений или целый диапазон наборов изменений. В нашем случае
- с отменой изменений, мы просим <command>svn merge</command>
+ изменений или целый диапазон наборов изменений. В нашем примере
+ с отменой изменений мы просим <command>svn merge</command>
применить к рабочей копии набор изменений #303
<emphasis>в обратном направлении</emphasis>.</para>
@@ -2182,16 +2181,16 @@
@ENGLISH }}} -->
<title>Subversion и наборы изменений</title>
- <para>У каждого найдется свое, немного отличающееся
- определение <quote>набора изменений</quote>, или во всяком
- случая того, что это должно означать применительно к системе
- управления версиями <quote>поддерживающей наборы
- изменений</quote>. Для нашего случая будем считать, что
- набор изменений это просто модификации объединенные под
+ <para>У каждого найдется свое собственное
+ определение <quote>набора изменений</quote>, или по крайней
+ мере того, что должна уметь система
+ управления версиями, <quote>поддерживающая наборы
+ изменений</quote>. В нашем случае будем считать, что
+ набор изменений — это просто изменения, объединенные неким
уникальным именем. Изменения могут заключаться в редактировании
текста файлов, модификации структуры файлов или корректировке
- метаданных. Проще говоря, набор изменений это просто патч
- с заданным для него именем.</para>
+ метаданных. Проще говоря, набор изменений — это просто
+ патч, идентифицируемый некоторым именем.</para>
<!-- @ENGLISH {{{
<para>In Subversion, a global revision number N names a tree
@@ -2215,22 +2214,22 @@
@ENGLISH }}} -->
<para>В Subversion глобальный номер правки N относится к
дереву в хранилище: так выглядит хранилище после
- фиксации N. Кроме того, это имя для неявного набора
+ фиксации N. Кроме того, это имя неявного набора
изменений: если сравнить дерево N с деревом N-1 вы получите
полный патч того, что было зафиксировано. В этом смысле,
о <quote>правке N</quote> можно думать не как о дереве
файлов, а как о наборе изменений. Если вы пользуетесь
системой отслеживания релизов для управления ошибками,
- вы можете использовать номера правок для того, что бы
+ вы можете использовать номера правок для того, чтобы
ссылаться на конкретные патчи, которые исправляют
ошибку — например, <quote>этот релиз был исправлен
- правкой 9238.</quote>. После этого, для того, что бы прочитать
- о том наборе изменений, который исправляет ошибку можно выполнить
- <command>svn log -r9238</command>, а для того, что бы увидеть
- сам патч, выполнить <command>svn diff -r9237:9238</command>.
- В Subversion команда <literal>merge</literal> тоже использует
+ правкой 9238.</quote>. Тогда, чтобы узнать набор изменений,
+ исправляющий заданную ошибку, можно выполнить
+ <command>svn log -r9238</command>, а чтобы увидеть
+ сам патч — запустить <command>svn diff -r9237:9238</command>.
+ Команда <literal>merge</literal> тоже использует
номера правок. Можно объединить набор изменений из одной ветки
- в другую указав его в качестве аргумента:
+ в другую, указав его в качестве аргумента:
команда <command>svn merge -r9237:9238</command> внедрит
набор изменений #9238 в вашу рабочую копию.</para>
@@ -2246,16 +2245,15 @@
committing, this particular changeset is no longer reflected
in the <literal>HEAD</literal> revision.</para>
@ENGLISH }}} -->
- <para>Обратите внимание, что откат изменений подобным образом
- ничем не отличается от любых других операций, выполненных с
- помощью <command>svn merge</command>, поэтому необходимо
- использовать <command>svn status</command> и <command>svn
- diff</command> для того, чтобы убедиться, что ваша
- работа находится в том состоянии, в котором вам нужно, а затем,
- используя <command>svn commit</command>, отправить финальную
- версию в хранилище. После фиксации этот конкретный набор
- изменений больше не будет отражен в правке
- <literal>HEAD</literal>.</para>
+ <para>Обратите внимание, что подобный откат изменений
+ ничем не отличается от остальных операций, выполняемых с
+ помощью <command>svn merge</command>. Поэтому необходимо
+ с помощью <command>svn status</command> и <command>svn
+ diff</command> убедиться в том, что результат соответствует
+ ожиданиям, а затем, используя <command>svn commit</command>,
+ отправить финальную версию в хранилище. После фиксации
+ этот конкретный набор изменений больше не будет отражен
+ в правке <literal>HEAD</literal>.</para>
<!-- @ENGLISH {{{
<para>Again, you may be thinking: well, that really didn't undo
@@ -2289,29 +2287,29 @@
</footnote>
</para>
@ENGLISH }}} -->
- <para>Но наряду с этим, вы можете подумать: однако же на самом деле
- фиксация не отменяется, не так ли? Изменения продолжают существовать
- в правке 303. И если кто-то создаст рабочую копию версии проекта
- <filename>calc</filename> между правками 303 и 349, он все равно
- получит ошибочные изменения, верно?</para>
-
- <para>Да, это так. Когда мы говорим об <quote>удалении</quote>
- изменений, имеется в виду их удаление из <literal>HEAD</literal>.
- Первоначальные изменения продолжают существовать в истории
- хранилища. Для большинства ситуаций это является положительным
- моментом. В любом случае, большинство пользователей интересует
- только <literal>HEAD</literal> проекта. Однако, возможны
- ситуации, когда действительно необходимо удалить последствия
- фиксации. (Возможно, кто-то случайно зафиксировал
- конфиденциальный документ.) Сделать это будет не так просто, так как
- Subversion спроектирована специально таким образом, что бы исключить
- возможность потери информации. Правки представляют собой не меняющиеся
- деревья файлов, основывающиеся одно на другом. Удаление правки из
- хранилища может вызвать эффект домино, создавая беспорядок во всех
- последующих правках и возможно разрушая все рабочие копии.
- <footnote><para>Однако, проект Subversion планирует со временем
- реализовать команду <command>svnadmin obliterate</command>
- с помощью которой можно будет выборочно удалять информацию.
+ <para>Давайте, однако, подумаем: отменяется ли на самом деле
+ предыдущая фиксация? Изменения продолжают существовать
+ в правке 303. И если кто-то создаст рабочую копию проекта
+ <filename>calc</filename> между правками 303 и 349, он ведь
+ все равно получит ошибочные изменения?</para>
+
+ <para>Безусловно, это так. Говоря об <quote>удалении</quote>
+ изменений, мы имеем в виду их удаление из правки <literal>HEAD</literal>.
+ Исходные изменения по-прежнему останутся в истории
+ хранилища. Чаще всего это можно рассматривать даже как
+ положительный момент. В любом случае, большинство пользователей
+ интересует только <literal>HEAD</literal>-правка проекта.
+ Однако, возможны ситуации, когда необходимо полностью удалить
+ последствия фиксации. (Например, если кто-то случайно зафиксировал
+ конфиденциальный документ.) Сделать это будет непросто, так как
+ архитектура Subversion намеренно исключает возможность потери
+ информации. Правки представляют собой не меняющиеся
+ деревья файлов, основанные друг на друге. Удаление правки из
+ хранилища может вызвать эффект домино, потащив за собой все
+ последующие правки и повредив все рабочие копии.
+ <footnote><para>Однако, разработчики Subversion в будущем планируют
+ реализовать команду <command>svnadmin obliterate</command>,
+ которая позволит полностью удалять информацию.
А пока за возможным решением проблемы обратитесь к разделу <xref
linkend="svn.reposadmin.maint.tk.svndumpfilter"/>.</para>
</footnote></para>
@@ -2342,22 +2340,21 @@
<sect2 id="svn.branchmerge.commonuses.resurrect">
<title>Восстановление удаленных элементов</title>
- <para>Отличным свойством системы контроля версий является то,
+ <para>Отличным свойством системы управления версиями является то,
что информация никогда не теряется. При удалении файла
- или директории, элемент исчезает из правки <literal>HEAD</literal>
- но продолжает существовать в более ранних правках. Одним
- из наиболее частых вопросов, задаваемых новыми пользователями,
- является такой: <quote>Как мне вернуть назад свой файл или
- директорию?</quote></para>
-
- <para>Первым шагом является определение того, <emphasis
- role="bold">какой именно</emphasis> элемент вы пытаетесь
- восстановить. Неплохой метафорой является представление
- каждого объекта в хранилище существующим в двухмерной системе
- координат. Первой координатой является отдельное дерево правок,
- второй координатой является путь в этом дереве. Таким образом
- каждая версия файла или директории может быть представлена
- конкретной парой координат.</para>
+ или каталога элемент исключается из правки <literal>HEAD</literal>,
+ но продолжает существовать в более ранних правках. Новые пользователи
+ очень часто спрашивают: <quote>Как мне вернуть назад свой файл или
+ каталог?</quote></para>
+
+ <para>Для начала было бы неплохо определиться, <emphasis
+ role="bold">какой именно</emphasis> элемент мы пытаемся
+ восстановить. Для этого полезно представить все объекты
+ хранилища как точки в двумерной системе координат.
+ Первой координатой будет отдельное дерево правок,
+ в второй — путь в этом дереве. Таким образом,
+ каждая версия файла или каталога может быть задана
+ парой координат.</para>
<!-- @ENGLISH {{{
<para>Subversion has no <filename>Attic</filename> directory
@@ -2378,22 +2375,23 @@
to examine the log output (via <command>grep</command>, or
perhaps via an incremental search in an editor).</para>
@ENGLISH }}} -->
- <para>Subversion, в отличие от CVS, не имеет директории
+ <para>В отличие от CVS, Subversion не имеет каталога
<filename>Attic</filename><footnote><para>Из-за того, что
CVS не версионирует деревья, она создает область
- <filename>Attic</filename> для каждой директории хранилища
- как способ запоминания удаленных файлов.</para></footnote>
- поэтому для определения необходимой при восстановлении пары
- координат нужно воспользоваться командой <command>svn
- log</command>. Лучше всего запустить <command>svn log
- --verbose</command> в директории, которая содержала
- удаленный элемент. Параметр <option>--verbose</option>
- покажет для каждой правки список измененных элементов;
- все, что вам остается сделать, это найти правку, в которой
- файл или директория были удалены. Сделать это можно
- визуально или воспользоваться для обработки вывода каким-то
- инструментом (<command>grep</command> или может быть
- последовательным поиском в редакторе).</para>
+ <filename>Attic</filename> для каждого каталога хранилища
+ как способ сохранения информации об удаленных
+ файлах.</para></footnote>,
+ поэтому для определения искомой пары координат восстанавливаемого
+ объекта нужно вызвать <command>svn log</command>.
+ Лучше всего запустить <command>svn log
+ --verbose</command> в каталоге, который содержал
+ удаленный объект. Параметр <option>--verbose</option>
+ покажет для каждой правки список измененных элементов —
+ в этом случае вам останется только найти ту правку, в которой
+ файл или каталог были удалены. Это можно сделать
+ визуально или обработав вывод команды каким-нибудь
+ инструментом (например, утилитой <command>grep</command> или
+ просто запустив поиск в редакторе).</para>
<screen>
$ cd parent-dir
@@ -2432,25 +2430,25 @@
The file would be scheduled for addition, and after a commit,
the file would again exist in <literal>HEAD</literal>.</para>
@ENGLISH }}} -->
- <para>В примере предполагается, что вы ищите удаленный файл
- <filename>real.c</filename>. Просмотрев логи родительской
- директории вы определите, что этот файл был удален в правке
- 808. Следовательно, последняя существовавшая версия файла
- была в правке, предшествующей этой. Вывод: необходимо из
+ <para>В этом примере предполагается, что вы ищете удаленный файл
+ <filename>real.c</filename>. Просмотрев логи родительского
+ каталога, вы можете заметить, что этот файл был удален в правке
+ 808. Следовательно, самая последняя версия этого файла
+ была в правке, предшествующей удалению. Вывод: необходимо из
правки 807 восстановить путь
<filename>/calc/trunk/real.c</filename>.</para>
- <para>Поиск был сложной задачей. Теперь, когда известно, что
- нужно восстановить, есть две возможности.</para>
+ <para>Поиск — непростая задача. Теперь, когда нам известно,
+ что именно нужно восстановить, есть две варианта действий.</para>
- <para>Одним из вариантов является использование <command>svn
- merge</command> для применения правки 808 <quote>в обратном
- направлении</quote>. (Как отменять изменения мы уже рассматривали,
+ <para>Во-первых, мы можем посредством <command>svn merge</command>
+ применить правку 808 <quote>в обратном
+ направлении</quote>. (Как отменять изменения, мы уже рассматривали,
см. <xref linkend="svn.branchmerge.commonuses.undo"/>.) Это
- приведет к эффекту повторного добавления фала
- <filename>real.c</filename> в виде локальных изменений.
- Файл будет запланирован для добавления и после фиксации
- будет опять присутствовать в <literal>HEAD</literal>.</para>
+ приведет к повторному добавлению файла
+ <filename>real.c</filename> в форме локального изменения.
+ Файл будет запланирован для добавления, и после фиксации
+ будет снова присутствовать в <literal>HEAD</literal>.</para>
<!-- @ENGLISH {{{
<para>In this particular example, however, this is probably not
@@ -2470,20 +2468,20 @@
revision and path <quote>coordinate pair</quote> from the
repository to your working copy:</para>
@ENGLISH }}} -->
- <para>Однако в этом, отдельно взятом примере, это не самое лучшее
+ <para>Однако, в данном примере это не самое лучшее
решение. Повторное применение правки 808 не только добавит
- файл <filename>real.c</filename>; лог сообщение показывает, что
+ файл <filename>real.c</filename>. Лог-сообщение показывает, что также
будут отменены некоторые изменения в <filename>integer.c</filename>,
- чего вы не хотите. Конечно, можно выполнить обратное объединение
+ что весьма нежелательно. Конечно, можно выполнить обратное слияние
с правкой 808, а затем отменить (<command>svn revert</command>)
- локальные изменения <filename>integer.c</filename>, однако такой
- подход плохо масштабируется. Что если в правке 808 было изменено
+ локальные изменения в <filename>integer.c</filename>, но такой
+ подход плохо масштабируется. Что, если в правке 808 изменилось
90 файлов?</para>
- <para>При втором, более целевом методе, <command>svn merge</command>
+ <para>При другом, более аккуратном подходе <command>svn merge</command>
вообще не используется, а вместо этого применяется команда
- <command>svn copy</command>. Просто скопируете определенные
- <quote>парой координат</quote> правку и путь из хранилища в
+ <command>svn copy</command>. Просто скопируйте объект, заданный
+ <quote>парой координат</quote> (правка и путь), из хранилища в
рабочую копию:</para>
<screen>
@@ -2514,19 +2512,18 @@
that these same techniques work just as well for resurrecting
deleted directories.</para>
@ENGLISH }}} -->
- <para>Знак плюс в статусе показывает, что элемент не просто
- запланирован для добавления, а запланирован для добавления
- <quote>с историей</quote>. Subversion запоминает откуда он был
- скопирован. В будущем, запуск <command>svn log</command> для
- этого файла будет пересекать восстановление файла и всю историю,
- предшествующую правке 807. Другими словами, новый файл
- <filename>real.c</filename> на самом деле не является новым;
- он является прямым наследником оригинального, удаленного
- файла.</para>
-
- <para>Хотя наш пример показывает как восстанавливать файл, обратите
- внимание, на то что этот подход работает также и для
- восстановления удаленных директорий.</para>
+ <para>Знак "плюс" в столбце статуса показывает, что
+ элемент не просто запланирован для добавления, а запланирован
+ для добавления <quote>с историей</quote>. Subversion запоминает,
+ откуда он был скопирован. В будущем вызов <command>svn log</command>
+ для этого файла будет пересекать точку восстановления файла и
+ прослеживать всю историю, предшествующую правке 807. Другими словами,
+ новый файл <filename>real.c</filename> на самом деле не является новым;
+ он является прямым потомком исходного файла, который был удален.</para>
+
+ <para>Хотя наш пример демонстрирует только восстановление файла,
+ отметим, что такой же подход будет работать и при
+ восстановлении удаленных каталогов.</para>
</sect2>
@@ -2547,20 +2544,20 @@
Still, it may help to see them described in Subversion
terms.</para>
@ENGLISH }}} -->
- <title>Типовые приемы при использовании веток</title>
+ <title>Типовые приемы использования веток</title>
<para>Управление версиями чаще всего используется при
разработке программного обеспечения, поэтому здесь мы
- вкратце рассмотрим два, наиболее часто используемые командами
- программистов, приема ветвления/слияния. Если вы не используете
+ вкратце рассмотрим два наиболее часто используемых командами
+ программистов приема ветвления/слияния. Если вы не используете
Subversion для разработки программного обеспечения, можете
- пропустить этот раздел. Если вы разработчик программного
- обеспечения использующий контроль версий впервые, внимательно
- присмотритесь, поскольку опытные разработчики считают использование
- этих приемов хорошим стилем работы. Такие приемы не являются
- специфичными для Subversion; они применимы к любой системе
- управления версиями. Тем более, что это поможет увидеть
- их описание в терминах Subversion.</para>
+ пропустить этот раздел. Если вы — разработчик программного
+ обеспечения, впервые использующий контроль версий, уделите этому
+ разделу пристальное внимание, поскольку опытные разработчики
+ считают использование данных приемов хорошим стилем.
+ Такие приемы не являются специфичными для Subversion;
+ они применимы к любой системе управления версиями.
+ Однако, здесь мы взглянем на них с позиций Subversion.</para>
<sect3 id="svn.branchmerge.commonuses.patterns.release">
<!-- @ENGLISH {{{
More information about the svnbook-dev
mailing list