ch-branching-and-merging.xml - svnbook - Project Hosting on Google Code

‹r3313

r3654

Source path: svn/ trunk/ src/ ru/ book/ ch-branching-and-merging.xml

<?xml version="1.0" encoding="UTF-8"?>
<chapter id="svn.branchmerge">
  <!-- @ENGLISH {{{
  <title>Branching and Merging</title>
  @ENGLISH }}} -->
  <title>Ветвление и слияние</title>
  <!-- See also svn.preface.organization -->

  <!-- @ENGLISH {{{
  <para>Branching, tagging, and merging are concepts common to
    almost all version control systems.  If you're not familiar with
    these ideas, we provide a good introduction in this chapter.  If
    you are familiar, then hopefully you'll find it interesting to
    see how Subversion implements these ideas.</para>

  <para>Branching is a fundamental part of version control.  If
    you're going to allow Subversion to manage your data, then this
    is a feature you'll eventually come to depend on.  This chapter
    assumes that you're already familiar with Subversion's basic
    concepts (<xref linkend="svn.basic"/>).</para>
  @ENGLISH }}} -->
  <para>Ветвление, назначение меток и слияние &mdash; это понятия, 
    свойственные практически всем системам управления версиями. Если 
    вы плохо знакомы с этими понятиями, то в этой главе вы с ними 
    обстоятельно познакомитесь. Если эти понятия вам уже знакомы, 
    то мы надеемся, что вам будет интересно узнать, как эти идеи 
    реализованы в Subversion.</para>

  <para>Ветвление &mdash; фундаментальное понятие управления версиями.
    Если вы собираетесь доверить Subversion управление своей информацией, 
    то это именно та функция, от которой вы впоследствии будете сильно 
    зависеть. Материал данной главы предполагает, что вы уже знакомы 
    с основными понятиями Subversion (<xref linkend="svn.basic"/>).</para>

  <!-- ================================================================= -->
  <!-- ================================================================= -->
  <!-- ================================================================= -->
  <sect1 id="svn.branchmerge.whatis">
    <!-- @ENGLISH {{{
    <title>What's a Branch?</title>

    <para>Suppose it's your job to maintain a document for a division
      in your company, a handbook of some sort.  One day a different
      division asks you for the same handbook, but with a few parts
      <quote>tweaked</quote> for them, since they do things slightly
      differently.</para>

    <para>What do you do in this situation?  You do the obvious thing:
      you make a second copy of your document, and begin maintaining
      the two copies separately.  As each department asks you to make
      small changes, you incorporate them into one copy or the
      other.</para>
    @ENGLISH }}} -->

    <title>Что такое ветка?</title>

    <para>Предположим, что ваша работа заключается в сопровождении
      документа (например, какого-то руководства) для подразделений
      вашей компании. Однажды различные подразделения запросят
      у вас одно и то же руководство, но при этом в несколько 
      <quote>адаптированном</quote> для них варианте, поскольку
      работа каждого подразделения имеет свою специфику.</para>

    <para>Как быть в такой ситуации? Скорее всего, вы 
      создадите вторую копию документа и начнёте отдельно сопровождать 
      обе копии. Когда какое-то из подразделений попросит вас
      внести небольшие изменения, вы включите их либо в первую копию, 
      либо во вторую.</para>

    <!-- @ENGLISH {{{
    <para>You often want to make the same change to both copies.  For
      example, if you discover a typo in the first copy, it's very
      likely that the same typo exists in the second copy.  The two
      documents are almost the same, after all; they only differ in
      small, specific ways.</para>

    <para>This is the basic concept of a
      <firstterm>branch</firstterm>&mdash;namely, a line of
      development that exists independently of another line, yet still
      shares a common history if you look far enough back in time.  A
      branch always begins life as a copy of something, and moves on
      from there, generating its own history (see <xref
      linkend="svn.branchmerge.whatis.dia-1"/>).</para>
    @ENGLISH }}} -->
    <para>Чаще всего вам придется вносить изменения в обе копии.
      Например, если вы обнаружите опечатку в одной копии, скорее
      всего, эта же опечатка будет присутствовать и в другой.
      Два документа, в общем-то, почти одинаковы &mdash; их различия
      сводятся к отдельным специфичным моментам.</para>

    <para>В этом заключается основная идея
      <firstterm>ветки</firstterm> &mdash; то есть направления разработки,
      которое существует независимо от другого направления, но
      имеет с ним общую историю, если заглянуть немного в прошлое.
      Ветка всегда берет начало как копия чего-либо и движется от
      этой точки, создавая свою собственную историю (см. <xref
      linkend="svn.branchmerge.whatis.dia-1"/>).</para>

    <!-- @ENGLISH {{{
      <figure id="svn.branchmerge.whatis.dia-1">
        <title>Branches of development</title>
        <graphic fileref="images/ch04dia1.png"/>
      </figure>

    <para>Subversion has commands to help you maintain parallel
      branches of your files and directories.  It allows you to create
      branches by copying your data, and remembers that the copies are
      related to one another.  It also helps you duplicate changes
      from one branch to another.  Finally, it can make portions of
      your working copy reflect different branches, so that you can
      <quote>mix and match</quote> different lines of development in
      your daily work.</para>
    @ENGLISH }}} -->
      <figure id="svn.branchmerge.whatis.dia-1">
        <title>Ветки разработки</title>
        <graphic fileref="images/ch04dia1.png"/>
      </figure>

    <para>В Subversion есть команды, которые помогают сопровождать
      параллельные ветки файлов и каталогов. Они позволяют создавать
      ветки, копируя данные и запоминая, что копии связаны
      друг с другом. Кроме того, эти команды помогают дублировать изменения
      из одной ветки в другую. Наконец, они могут сделать так, что отдельные 
      части рабочей копии будут отражать состояние различных веток, 
      что позволит вам <quote>смешивать и согласовывать</quote> различные 
      линии разработки в своей каждодневной работе.</para>

  </sect1>

  <!-- ================================================================= -->
  <!-- ================================================================= -->
  <!-- ================================================================= -->
  <sect1 id="svn.branchmerge.using">
    <!-- @ENGLISH {{{
    <title>Using Branches</title>

    <para>At this point, you should understand how each commit creates
      an entire new filesystem tree (called a <quote>revision</quote>)
      in the repository.  If not, go back and read about revisions in
      <xref linkend="svn.basic.in-action.revs"/>.</para>

    <para>For this chapter, we'll go back to the same example from
      <xref linkend="svn.basic"/>.  Remember that you and your
      collaborator, Sally, are sharing a repository that contains two
      projects, <filename>paint</filename> and
      <filename>calc</filename>.  Notice that in <xref
      linkend="svn.branchmerge.using.dia-1"/>, however, each project
      directory now contains subdirectories named
      <filename>trunk</filename> and <filename>branches</filename>.
      The reason for this will soon become clear.</para>
    @ENGLISH }}} -->
    <title>Использование веток</title>

    <para>К этому моменту вы должны понимать, что в хранилище при каждой
      фиксации создается полностью новое дерево файлов (называемое
      <quote>правка</quote>). Если нет, то вернитесь назад и прочитайте
      о правках в разделе <xref linkend="svn.basic.in-action.revs"/>.</para>

    <para>В этой главе мы воспользуемся тем же примером, что и
      в <xref linkend="svn.basic"/>. Как вы помните, вы и ваш соразработчик
      Салли совместно используете хранилище, содержащее два проекта,
      <filename>paint</filename> и <filename>calc</filename>. Как
      отмечалось в <xref linkend="svn.branchmerge.using.dia-1"/>, каждый
      каталог проекта содержит подкаталоги с именами
      <filename>trunk</filename> и <filename>branches</filename>.
      Назначение этих каталогов вскоре станет понятно.</para>

      <figure id="svn.branchmerge.using.dia-1">
        <!-- @ENGLISH {{{
        <title>Starting repository layout</title>
        @ENGLISH }}} -->
        <title>Начальная структура хранилища</title>
        <graphic fileref="images/ch04dia2.png"/>
      </figure>

    <!-- @ENGLISH {{{
    <para>As before, assume that Sally and you both have working
      copies of the <quote>calc</quote> project.  Specifically, you
      each have a working copy of <filename>/calc/trunk</filename>.
      All the files for the project are in this subdirectory rather
      than in <filename>/calc</filename> itself, because your team has
      decided that <filename>/calc/trunk</filename> is where the
      <quote>main line</quote> of development is going to take
      place.</para>

    <para>Let's say that you've been given the task of performing a
      radical reorganization of the project.  It will take a long time
      to write, and will affect all the files in the project.  The
      problem here is that you don't want to interfere with Sally, who
      is in the process of fixing small bugs here and there.  She's
      depending on the fact that the latest version of the project (in
      <filename>/calc/trunk</filename>) is always usable.  If you
      start committing your changes bit-by-bit, you'll surely break
      things for Sally.</para>
    @ENGLISH }}} -->
    <para>Как и раньше, предположим, что и Салли, и вы имеете
      рабочие копии проекта <quote>calc</quote>. Точнее, каждый
      из вас имеет рабочую копию <filename>/calc/trunk</filename>.
      Все файлы, относящиеся к проекту, находятся в этом подкаталоге,
      а не прямо в <filename>/calc</filename>, потому что ваша команда
      решила размещать <quote>главную линию</quote> разработки в
      <filename>/calc/trunk</filename>.</para>


    <para>Допустим, перед вами была поставлена задача коренной реорганизации
      проекта. Это займет много времени и затронет все файлы проекта.
      Проблема заключается в том, что вы не хотите мешать Салли, которая
      прямо сейчас занимается исправлением небольших ошибок. Ее работа
      зависит от постоянной доступности последней версии проекта (каталога
      <filename>/calc/trunk</filename>). Если вы начнете пошагово фиксировать
      свои изменения, вы конечно же смешаете Салли все карты.</para>

    <!-- @ENGLISH {{{
    <para>One strategy is to crawl into a hole: you and Sally can stop
      sharing information for a week or two.  That is, start gutting
      and reorganizing all the files in your working copy, but don't
      commit or update until you're completely finished with the task.
      There are a number of problems with this, though.  First, it's
      not very safe.  Most people like to save their work to the
      repository frequently, should something bad accidentally happen
      to their working copy.  Second, it's not very flexible.  If you
      do your work on different computers (perhaps you have a working
      copy of <filename>/calc/trunk</filename> on two different
      machines), you'll need to manually copy your changes back and
      forth, or just do all the work on a single computer.  By that
      same token, it's difficult to share your changes-in-progress
      with anyone else.  A common software development <quote>best
      practice</quote> is to allow your peers to review your work as you
      go.  If nobody sees your intermediate commits, you lose
      potential feedback.  Finally, when you're finished with all your
      changes, you might find it very difficult to re-merge your final
      work with the rest of the company's main body of code.  Sally
      (or others) may have made many other changes in the repository
      that are difficult to incorporate into your working
      copy&mdash;especially if you run <command>svn update</command>
      after weeks of isolation.</para>
    @ENGLISH }}} -->
    <para>Одним из вариантов является временная изоляция:
      вы и Салли перестаете делиться информацией на неделю или две.
      В это время вы начинаете перелопачивать и реорганизовывать файлы
      рабочей копии, но не фиксируете и не обновляете ее до завершения 
      работы над задачей. Однако, в этом случае появляется несколько
      проблем. Во-первых, это не очень надежно. Большинство людей
      предпочитают часто сохранять свою работу в хранилище на случай, если
      с рабочей копией вдруг случится что-то плохое. Во-вторых, это не
      достаточно гибко. Если вы работаете на разных компьютерах
      (к примеру, если рабочая копия <filename>/calc/trunk</filename>
      есть у вас на двух разных машинах), вам придется вручную копировать
      изменения туда и обратно, либо делать всю работу на одном
      компьютере. С другой стороны, вам трудно делиться вносимыми
      изменениями с кем-то еще. А предоставление возможности 
      знакомиться с проделанной вами работой по мере ее продвижения
      считается <quote>наилучшей практикой</quote> при разработке 
      любого программного обеспечения. Если никто не будет видеть 
      ваших промежуточных фиксаций, вы теряете
      потенциал обратной связи. Наконец, когда вы закончите свои 
      изменения, может выясниться, что слить проделанную вами работу
      с остальным программным кодом компании чрезвычайно трудно.
      Салли (или кто-то другой) могла внести такие изменения в
      хранилище, которые трудно совместить с вашей рабочей копией
      &mdash; особенно, если вы выполните <command>svn update</command>
      впервые после нескольких недель изоляции.</para>


    <!-- @ENGLISH {{{
    <para>The better solution is to create your own branch, or line of
      development, in the repository.  This allows you to save your
      half-broken work frequently without interfering with others, yet
      you can still selectively share information with your
      collaborators.  You'll see exactly how this works later
      on.</para>
    @ENGLISH }}} -->
    <para>Наилучшим решением будет создание в хранилище вашей собственной 
      ветки, или направления разработки. Это позволит вам сохранять
      наполовину поломанную работу сколь угодно часто, не пересекаясь 
      с другими, и кроме того, вы сможете выборочно делиться
      информацией с другими коллегами.
      Дальше вы увидите, как всё это работает.</para>

    <!-- =============================================================== -->
    <sect2 id="svn.branchmerge.using.create">
      <!-- @ENGLISH {{{
      <title>Creating a Branch</title>

      <para>Creating a branch is very simple&mdash;you make a copy of
        the project in the repository using the <command>svn
        copy</command> command.  Subversion is not only able to copy
        single files, but whole directories as well.  In this case,
        you want to make a copy of the
        <filename>/calc/trunk</filename> directory.  Where should the
        new copy live?  Wherever you wish&mdash;it's a matter of
        project policy.  Let's say that your team has a policy of
        creating branches in the <filename>/calc/branches</filename>
        area of the repository, and you want to name your branch
        <literal>my-calc-branch</literal>.  You'll want to create a
        new directory,
        <filename>/calc/branches/my-calc-branch</filename>, which
        begins its life as a copy of
        <filename>/calc/trunk</filename>.</para>

      <para>There are two different ways to make a copy.  We'll
        demonstrate the messy way first, just to make the concept
        clear.  To begin, check out a working copy of the project's
        root directory, <filename>/calc</filename>:</para>
      @ENGLISH }}} -->
      <title>Создание ветки</title>

      <para>Создать ветку очень просто &mdash; при помощи команды
        <command>svn copy</command> в хранилище создается копия проекта.
        Subversion может копировать не только отдельные файлы, но и
        целые каталоги. Итак, вам нужно сделать копию каталога
        <filename>/calc/trunk</filename>. Где должна лежать эта
        новая копия? Где угодно &mdash; этот вопрос определяется
        правилами проекта. Допустим, что по правилам вашей команды 
        ветки создаются в каталоге <filename>/calc/branches</filename>
        хранилища, и вы хотите назвать свою ветку
        <literal>my-calc-branch</literal>. Тогда вам следует создать новый
        каталог <filename>/calc/branches/my-calc-branch</filename>,
        который будет копией <filename>/calc/trunk</filename>.</para>

      <para>Копию можно создать двумя различными способами. Сперва мы покажем
        более длинный способ, просто для того, что бы пояснить суть идеи.
        Для начала создадим рабочую копию корневого каталога проекта
        <filename>/calc</filename>:</para>

      <screen>
$ svn checkout http://svn.example.com/repos/calc bigwc
A  bigwc/trunk/
A  bigwc/trunk/Makefile
A  bigwc/trunk/integer.c
A  bigwc/trunk/button.c
A  bigwc/branches/
Checked out revision 340.
</screen>

      <!-- @ENGLISH {{{
      <para>Making a copy is now simply a matter of passing two
        working-copy paths to the <command>svn copy</command>
        command:</para>
      @ENGLISH }}} -->
      <para>Теперь, чтобы создать копию, достаточно просто передать
        два пути в пределах рабочей копии команде
        <command>svn copy</command>:</para>

      <screen>
$ cd bigwc
$ svn copy trunk branches/my-calc-branch
$ svn status
A  +   branches/my-calc-branch
</screen>

      <!-- @ENGLISH {{{
      <para>In this case, the <command>svn copy</command> command
        recursively copies the <filename>trunk</filename> working
        directory to a new working directory,
        <filename>branches/my-calc-branch</filename>.  As you can see
        from the <command>svn status</command> command, the new
        directory is now scheduled for addition to the repository.
        But also notice the <quote>+</quote> sign next to the letter
        A.  This indicates that the scheduled addition is a
        <emphasis>copy</emphasis> of something, not something new.
        When you commit your changes, Subversion will create
        <filename>/calc/branches/my-calc-branch</filename> in the
        repository by copying <filename>/calc/trunk</filename>, rather
        than resending all of the working copy data over the
        network:</para>
      @ENGLISH }}} -->
      <para>В результате команда <command>svn copy</command>
        рекурсивно копирует рабочий каталог <filename>trunk</filename>
        в новый рабочий каталог
        <filename>branches/my-calc-branch</filename>. Теперь команда
        <command>svn status</command> покажет, что новый каталог
        запланирован для добавления в хранилище. Обратите внимание
        на знак <quote>+</quote> после буквы А. Он означает, что
        запланированное для добавления представляет собой какую-то
        <emphasis>копию</emphasis>, а не что-то новое.
        При следующей фиксации Subversion создаст в хранилище 
        каталог <filename>/calc/branches/my-calc-branch</filename>,
        скопировав его из <filename>/calc/trunk</filename>
        вместо того, чтобы повторно отправлять по сети
        всю информацию рабочей копии:</para>

      <screen>
$ svn commit -m "Creating a private branch of /calc/trunk."
Adding         branches/my-calc-branch
Committed revision 341.
</screen>

      <!-- @ENGLISH {{{
      <para>And now the easier method of creating a branch, which we
        should have told you about in the first place: <command>svn
        copy</command> is able to operate directly on two URLs.</para>
      @ENGLISH }}} -->
      <para>А теперь покажем простой способ создания ветки, о котором мы 
        упоминали раньше: команда <command>svn copy</command> может 
        оперировать двумя URL-адресами напрямую.</para>

      <screen>
$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Creating a private branch of /calc/trunk."

Committed revision 341.
</screen>


      <!-- @ENGLISH {{{
      <para>There's really no difference between these two methods.
        Both procedures create a new directory in revision 341, and
        the new directory is a copy of
        <filename>/calc/trunk</filename>.  This is shown in <xref
        linkend="svn.branchmerge.using.create.dia-1"/>.  Notice that the second method,
        however, performs an <emphasis>immediate</emphasis> commit.
        <footnote>
          <para>Subversion does not support
            cross-repository copying.  When using URLs with <command>svn
            copy</command> or <command>svn move</command>, you can only
            copy items within the same repository.</para>
        </footnote>
        It's an easier procedure, because it doesn't require you to
        check out a large mirror of the repository.  In fact, this
        technique doesn't even require you to have a working copy at
        all.</para>
      @ENGLISH }}} -->
      <para>В сущности, между этими двумя методами нет разницы. Оба варианта
        создают в правке 341 новый каталог, и этой новый каталог является
        копией <filename>/calc/trunk</filename>. Это показывает <xref
        linkend="svn.branchmerge.using.create.dia-1"/>. Обратите 
        внимание на то, что второй метод, кроме всего прочего, выполняет
        <emphasis>немедленную</emphasis> фиксацию. <footnote>
        <para>Subversion не поддерживает возможность копирования между 
        хранилищами. При использовании  в командах <command>svn copy</command> 
        или <command>svn move</command> URL-адресов можно копировать только 
        элементы из одного и того же хранилища.</para>
        </footnote>Эта процедура более проста в использовании, так как нет
        необходимости в выгрузке в рабочую копию значительного объема данных
        из хранилища. По сути, в этом случае можно вовсе не иметь рабочей
        копии.</para>

      <figure id="svn.branchmerge.using.create.dia-1">
        <!-- @ENGLISH {{{
        <title>Repository with new copy</title>
        @ENGLISH }}} -->
        <title>Хранилище, содержащее новую копию</title>
        <graphic fileref="images/ch04dia3.png"/>
      </figure>

      <!-- @ENGLISH {{{
      <sidebar>
        <title>Cheap Copies</title>

        <para>Subversion's repository has a special design.  When you
          copy a directory, you don't need to worry about the
          repository growing huge&mdash;Subversion doesn't actually
          duplicate any data.  Instead, it creates a new directory
          entry that points to an <emphasis>existing</emphasis> tree.
          If you're a Unix user, this is the same concept as a
          hard-link.  From there, the copy is said to be
          <quote>lazy</quote>.  That is, if you commit a change to one
          file within the copied directory, then only that file
          changes&mdash;the rest of the files continue to exist as
          links to the original files in the original
          directory.</para>

        <para>This is why you'll often hear Subversion users talk
          about <quote>cheap copies</quote>.  It doesn't matter how
          large the directory is&mdash;it takes a very tiny, constant
          amount of time to make a copy of it.  In fact, this feature
          is the basis of how commits work in Subversion: each
          revision is a <quote>cheap copy</quote> of the previous
          revision, with a few items lazily changed within.  (To read
          more about this, visit Subversion's website and read about
          the <quote>bubble up</quote> method in Subversion's design
          documents.)</para>

        <para>Of course, these internal mechanics of copying and
          sharing data are hidden from the user, who simply sees
          copies of trees.  The main point here is that copies are
          cheap, both in time and space.  Make branches as often as
          you want.</para>
      </sidebar>
      @ENGLISH }}} -->
      <sidebar>
        <title>Легкие копии</title>

        <para>Хранилище Subversion устроено особым образом.
          При копировании каталога нет необходимости задумываться о
          большом увеличении размера хранилища &mdash; на самом деле
          Subversion никогда не дублирует информацию. Вместо этого
          создается новая точка входа в каталог, которая указывает на
          <emphasis>существующее</emphasis> дерево файлов. Если вы
          пользователь Unix, это тот же подход, что используется
          для жестких ссылок. То есть копия, так сказать, стала
          <quote>ленивой</quote>. Если в скопированном каталоге
          вы измените только один файл, при фиксации изменится только
          он &mdash; остальные файлы продолжат существовать как 
          ссылки на исходные файлы в исходном каталоге.</para>

        <para>Вот почему в разговорах пользователей Subversion часто можно
          услышать о <quote>легких копиях</quote>. Не имеет значения,
          насколько велик каталог &mdash; создание копии займет
          очень небольшой фиксированный промежуток времени. Фактически,
          на этом подходе основана работа фиксаций в Subversion: каждая
          правка является <quote>легкой копией</quote> предыдущей правки,
          с несколькими элементами, лениво измененными в ней. (Чтобы узнать
          подробности, посетите веб-сайт Subversion и прочитайте в
          документации по архитектуре Subversion о методе <quote>всплывающих
          пузырьков</quote>.)</para>

        <para>Конечно, эти внутренние механизмы копирования и совместного 
          использования информации скрыты от пользователя, который видит 
          просто копии файлов. Главное здесь то, что копии &mdash; легкие
          как по времени, так и по размеру. Делайте ветки так часто, как
          вам необходимо.</para>

      </sidebar>

    </sect2>

    <!-- =============================================================== -->
    <sect2 id="svn.branchmerge.using.work">
      <!-- @ENGLISH {{{
      <title>Working with Your Branch</title>

      <para>Now that you've created a branch of the project, you can
        check out a new working copy to start using it:</para>
      @ENGLISH }}} -->
      <title>Работа с веткой</title>

      <para>После создания ветки проекта можно загрузить новую рабочую копию
        и приступить к работе с ней:</para>

      <screen>
$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
A  my-calc-branch/Makefile
A  my-calc-branch/integer.c
A  my-calc-branch/button.c
Checked out revision 341.
</screen>

      <!-- @ENGLISH {{{
      <para>There's nothing special about this working copy; it simply
        mirrors a different directory in the repository.  When you
        commit changes, however, Sally won't ever see them when she
        updates.  Her working copy is of
        <filename>/calc/trunk</filename>.  (Be sure to read <xref
        linkend="svn.branchmerge.switchwc"/> later in this chapter: the
        <command>svn switch</command> command is an alternate way of
        creating a working copy of a branch.)</para>

      <para>Let's pretend that a week goes by, and the following
        commits happen:</para>
      @ENGLISH }}} -->
      <para>В этой рабочей копии нет ничего особенного; это 
        просто зеркало другого каталога хранилища. Однако, если Салли 
        обновит свою рабочую копию, она не увидит там ваших изменений.
        Рабочая копия Салли создана из каталога 
        <filename>/calc/trunk</filename>. (Смотрите далее в этой главе
        раздел <xref linkend="svn.branchmerge.switchwc"/>: команда
        <command>svn switch</command> является альтернативным способом
        создания рабочей копии ветки.)</para>

      <para>Предположим, что за неделю были сделаны следующие
        фиксации:</para>

      <!-- @ENGLISH {{{
      <itemizedlist>
        <listitem><para>
          You make a change to
          <filename>/calc/branches/my-calc-branch/button.c</filename>,
          which creates revision 342.</para>
        </listitem>

        <listitem><para>
          You make a change to
          <filename>/calc/branches/my-calc-branch/integer.c</filename>,
          which creates revision 343.</para>
        </listitem>

        <listitem><para>
          Sally makes a change to
          <filename>/calc/trunk/integer.c</filename>, which creates
          revision 344.</para>
        </listitem>
      </itemizedlist>
      @ENGLISH }}} -->
      <itemizedlist>
        <listitem><para>Вы внесли изменения в
          <filename>/calc/branches/my-calc-branch/button.c</filename>,
          создав таким образом правку 342.</para>
        </listitem>

        <listitem><para>Вы внесли изменения в
          <filename>/calc/branches/my-calc-branch/integer.c</filename>,
          создав правку 343.</para>
        </listitem>

        <listitem><para>Салли внесла изменения в
          <filename>/calc/trunk/integer.c</filename>, создав
          правку 344.</para>
        </listitem>
      </itemizedlist>

      <!-- @ENGLISH {{{
      <para>There are now two independent lines of development, shown
        in <xref linkend="svn.branchmerge.using.work.dia-1"/>, happening on
        <filename>integer.c</filename>.</para>


      <figure id="svn.branchmerge.using.work.dia-1">
        <title>The branching of one file's history</title>
        <graphic fileref="images/ch04dia4.png"/>
      </figure>

      <para>Things get interesting when you look at the history of
        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>

      <figure id="svn.branchmerge.using.work.dia-1">
        <title>История ветвления для одного файла</title>
        <graphic fileref="images/ch04dia4.png"/>
      </figure>

      <para>Если посмотреть историю изменений, сделанных в вашей копии
        <filename>integer.c</filename>, можно увидеть интересные
        вещи:</para>

      <screen>
$ pwd
/home/user/my-calc-branch

$ svn log --verbose integer.c
------------------------------------------------------------------------
r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   M /calc/branches/my-calc-branch/integer.c

* integer.c:  frozzled the wazjub.

------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

Creating a private branch of /calc/trunk.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  adding this file to the project.

------------------------------------------------------------------------
</screen>

      <!-- @ENGLISH {{{
      <para>Notice that Subversion is tracing the history of your
        branch's <filename>integer.c</filename> all the way back
        through time, even traversing the point where it was copied.
        It shows the creation of the branch as an event in the
        history, because <filename>integer.c</filename> was implicitly
        copied when all of <filename>/calc/trunk/</filename> was
        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> во времени,
        в том числе пересекая точку создания копии. Создание ветки
        показано как событие в истории, потому что файл
        <filename>integer.c</filename> был неявно скопирован при
        копировании всего каталога <filename>/calc/trunk/</filename>.
        Теперь давайте посмотрим, какой результат выдаст такая же
        команда для Салли:</para>

      <screen>
$ pwd
/home/sally/calc

$ svn log --verbose integer.c
------------------------------------------------------------------------
r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  fix a bunch of spelling errors.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  adding this file to the project.

------------------------------------------------------------------------
</screen>

      <!-- @ENGLISH {{{
      <para>Sally sees her own revision 344 change, but not the change
        you made in revision 343.  As far as Subversion is concerned,
        these two commits affected different files in different
        repository locations.  However, Subversion
        <emphasis>does</emphasis> show that the two files share a
        common history.  Before the branch-copy was made in revision
        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 &mdash; нет. Subversion 
        позаботилась о том, чтобы эти две фиксации затронули разные 
        файлы, имеющие разное расположение в хранилище. Тем не менее, 
        Subversion <emphasis>будет</emphasis> показывать то, что два файла 
        имеют общую историю. До создания ветки-копии в правке 341 это был 
        один файл. Поэтому и вы, и Салли видите изменения, сделанные в 
        правках 303 и 98.</para>

    </sect2>

    <!-- =============================================================== -->
    <sect2 id="svn.branchmerge.using.concepts">
      <!-- @ENGLISH {{{
      <title>The Key Concepts Behind Branches</title>

      <para>There are two important lessons that you should remember
        from this section.</para>

      <orderedlist>
        <listitem>
          <para>Unlike many other version control systems,
            Subversion's branches exist as <emphasis>normal filesystem
            directories</emphasis> in the repository, not in an extra
            dimension.  These directories just happen to carry some
            extra historical information.</para>
        </listitem>
        <listitem>
          <para>Subversion has no internal concept of a
            branch&mdash;only copies.  When you copy a directory, the
            resulting directory is only a <quote>branch</quote>
            because <emphasis>you</emphasis> attach that meaning to
            it.  You may think of the directory differently, or treat
            it differently, but to Subversion it's just an ordinary
            directory that happens to have been created by
            copying.</para>
        </listitem>
      </orderedlist>
      @ENGLISH }}} -->
      <title>Ключевые идеи, стоящие за ветками</title>

      <para>Из этого раздела вы должны запомнить две вещи.</para>

      <orderedlist>
        <listitem>
          <para>В отличие от многих других систем управления версиями,
          в хранилище Subversion ветки существуют не в отдельном измерении,
          а как <emphasis>обычные каталоги файловой системы</emphasis>. 
          Эти каталоги отличаются только тем, что несут дополнительную
          информацию о своей истории.</para>
        </listitem>
        <listitem>
          <para>Subversion не имеет такого понятия как ветка &mdash;
            есть только копии. Копия каталога
            становится <quote>веткой</quote> только потому, что
            <emphasis>вы</emphasis> рассматриваете ее таким образом.
            Вы можете по-разному думать о каталоге, по разному его 
            трактовать, но для Subversion это не более чем обычный каталог,
            созданный в результате копирования.</para>
        </listitem>
      </orderedlist>

    </sect2>

  </sect1>

  <!-- ================================================================= -->
  <!-- ================================================================= -->
  <!-- ================================================================= -->
  <sect1 id="svn.branchmerge.copychanges">
    <!-- @ENGLISH {{{
    <title>Copying Changes Between Branches</title>

    <para>Now you and Sally are working on parallel branches of the
      project: you're working on a private branch, and Sally is
      working on the <firstterm>trunk</firstterm>, or main line of
      development.</para>

    <para>For projects that have a large number of contributors, it's
      common for most people to have working copies of the trunk.
      Whenever someone needs to make a long-running change that is
      likely to disrupt the trunk, a standard procedure is to create a
      private branch and commit changes there until all the work is
      complete.</para>
    @ENGLISH }}} -->
    <title>Копирование изменений между ветками</title>


    <para>Теперь вы и Салли работаете над параллельными ветками проекта:
      вы &mdash; над своей собственной веткой, а Салли &mdash; над
      главной линией разработки 
      (каталог <firstterm>trunk</firstterm>).</para>

    <para>В проектах со значительным числом участников, как правило,
      большинство работает в главной линии разработки.
      Когда кому-то необходимо сделать изменения, которые займут
      много времени и могут нарушить главную линию, стандартной практикой
      является создание отдельной ветки и фиксация всех изменений в ней
      &mdash; до тех пор, пока работа не будет полностью завершена.</para>

    <!-- @ENGLISH {{{
    <para>So, the good news is that you and Sally aren't interfering
      with each other.  The bad news is that it's very easy to drift
      <emphasis>too</emphasis> far apart.  Remember that one of the
      problems with the <quote>crawl in a hole</quote> strategy is
      that by the time you're finished with your branch, it may be
      near-impossible to merge your changes back into the trunk
      without a huge number of conflicts.</para>

    <para>Instead, you and Sally might continue to share changes as
      you work.  It's up to you to decide which changes are worth
      sharing; Subversion gives you the ability to selectively
      <quote>copy</quote> changes between branches.  And when you're
      completely finished with your branch, your entire set of branch
      changes can be copied back into the trunk.</para>
    @ENGLISH }}} -->
    <para>Положительным моментом здесь является то, что вы и Салли не
      пересекаетесь друг с другом. Но есть и минус &mdash; 
      вы можете разойтись <emphasis>слишком</emphasis> далеко друг
      относительно друга. Помните, что одна из проблем такой
      стратегии <quote>временной изоляции</quote> заключается в том,
      что к моменту, когда вы завершите работу со своей веткой,
      может оказаться практически невозможным объединить ее 
      с главной линией без огромного количества конфликтов.</para>

    <para>Вместо этого вы и Салли можете продолжать делиться изменениями
      по ходу работы. Вы можете решать вплоть до отдельного изменения,
      стоит ли им делиться &mdash; Subversion предоставляет возможность
      выборочного <quote>копирования</quote> изменений между ветками.
      А тогда, когда вы полностью закончите работу со своей веткой, 
      вы можете скопировать обратно в основную ветку все изменения 
      полностью.</para>

    <!-- =============================================================== -->
    <sect2 id="svn.branchmerge.copychanges.specific">
      <!-- @ENGLISH {{{
      <title>Copying Specific Changes</title>


      <para>In the previous section, we mentioned that both you and
        Sally made changes to <filename>integer.c</filename> on
        different branches.  If you look at Sally's log message for
        revision 344, you can see that she fixed some spelling errors.
        No doubt, your copy of the same file still has the same spelling
        errors.  It's likely that your future changes to this file will
        be affecting the same areas that have the spelling errors, so
        you're in for some potential conflicts when you merge your
        branch someday.  It's better, then, to receive Sally's change
        now, <emphasis>before</emphasis> you start working too heavily
        in the same places.</para>

      <para>It's time to use the <command>svn merge</command> command.
        This command, it turns out, is a very close cousin to the
        <command>svn diff</command> command (which you read about in
        <xref linkend="svn.tour"/>).  Both commands are able to
        compare any two objects in the repository and describe the
        differences.  For example, you can ask <command>svn
        diff</command> to show you the exact change made by Sally in
        revision 344:</para>
      @ENGLISH }}} -->
      <title>Копирование отдельных изменений</title>

      <para>В предыдущем разделе мы отметили, что и вы, и Салли, 
        одновременно, в разных ветках вносите изменения в файл
        <filename>integer.c</filename>.
        Если посмотреть на лог-сообщение Салли для правки 344, вы увидите,
        что она исправила несколько орфографических ошибок. Конечно же,
        в вашей копии этого файла эти ошибки остались. Не исключено, что
        ваши будущие изменения этого файла коснутся областей, 
        содержащих эти орфографические ошибки, и таким образом вы получите 
        несколько потенциальных конфликтов при последующем объединении 
        вашей ветки. Поэтому лучше получить изменения от Салли сейчас,
        <emphasis>до</emphasis> того, как вы начнете вплотную работать с
        этой частью файла.</para>

      <para>Настал момент воспользоваться командой <command>svn
        merge</command>. Эта команда, оказывается, является очень близким
        родственником команды <command>svn diff</command> (о которой вы
        читали в <xref linkend="svn.tour"/>). Обе команды способны
        сравнивать любые два объекта в хранилище и показывать различия.
        Например, вы можете попросить <command>svn diff</command> показать
        все изменения, сделанные Салли в правке 344:</para>

      <screen>
$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk

Index: integer.c
===================================================================
--- integer.c (revision 343)
+++ integer.c (revision 344)
@@ -147,7 +147,7 @@
     case 6:  sprintf(info-&gt;operating_system, "HPFS (OS/2 or NT)"); break;
     case 7:  sprintf(info-&gt;operating_system, "Macintosh"); break;
     case 8:  sprintf(info-&gt;operating_system, "Z-System"); break;
-    case 9:  sprintf(info-&gt;operating_system, "CPM"); break;
+    case 9:  sprintf(info-&gt;operating_system, "CP/M"); break;
     case 10:  sprintf(info-&gt;operating_system, "TOPS-20"); break;
     case 11:  sprintf(info-&gt;operating_system, "NTFS (Windows NT)"); break;
     case 12:  sprintf(info-&gt;operating_system, "QDOS"); break;
@@ -164,7 +164,7 @@
     low = (unsigned short) read_byte(gzfile);  /* read LSB */
     high = (unsigned short) read_byte(gzfile); /* read MSB */
     high = high &lt;&lt; 8;  /* interpret MSB correctly */
-    total = low + high; /* add them togethe for correct total */
+    total = low + high; /* add them together for correct total */

     info-&gt;extra_header = (unsigned char *) my_malloc(total);
     fread(info-&gt;extra_header, total, 1, gzfile);
@@ -241,7 +241,7 @@
      Store the offset with ftell() ! */

   if ((info-&gt;data_offset = ftell(gzfile))== -1) {
-    printf("error: ftell() retturned -1.\n");
+    printf("error: ftell() returned -1.\n");
     exit(1);
   }

@@ -249,7 +249,7 @@
   printf("I believe start of compressed data is %u\n", info-&gt;data_offset);
   #endif

-  /* Set postion eight bytes from the end of the file. */
+  /* Set position eight bytes from the end of the file. */

   if (fseek(gzfile, -8, SEEK_END)) {
     printf("error: fseek() returned non-zero\n");
</screen>

      <!-- @ENGLISH {{{
      <para>The <command>svn merge</command> command is almost exactly
        the same.  Instead of printing the differences to your
        terminal, however, it applies them directly to your working
        copy as <emphasis>local modifications</emphasis>:</para>
      @ENGLISH }}} -->
      <para>Команда <command>svn merge</command> ведет себя 
        практически идентично. Но вместо вывода различий на терминал
        она применяет их к рабочей копии в виде <emphasis>локальных
        изменений</emphasis>:</para>

      <screen>
$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c
</screen>

      <!-- @ENGLISH {{{
      <para>The output of <command>svn merge</command> shows that your
        copy of <filename>integer.c</filename> was patched.  It now
        contains Sally's change&mdash;the change has been
        <quote>copied</quote> from the trunk to your working copy of
        your private branch, and now exists as a local modification.
        At this point, it's up to you to review the local modification
        and make sure it works correctly.</para>

      <para>In another scenario, it's possible that things may not have
        gone so well, and that <filename>integer.c</filename> may have
        entered a conflicted state.  You might need to resolve the
        conflict using standard procedures (see <xref
        linkend="svn.tour"/>), or if you decide that the merge was a
        bad idea altogether, simply give up and <command>svn
        revert</command> the local change.</para>
      @ENGLISH }}} -->
      <para>Вывод команды <command>svn merge</command> показывает, что
        к вашей копии <filename>integer.c</filename> был применен патч.
        Теперь она содержит изменения Салли &mdash; они были
        <quote>скопированы</quote> из главной линии разработки в вашу
        рабочую копию, вашу собственную ветку, и теперь существуют в виде
        локальных изменений. С этого момента вы можете просмотреть локальные
        изменения и убедиться в том, что они корректны.</para>

      <para>Возможна ситуация, когда не все будет так хорошо
        и <filename>integer.c</filename> окажется в состоянии
        конфликта. Тогда вам будет необходимо разрешить конфликт
        обычным путем (см. <xref linkend="svn.tour"/>), либо, если вы
        придете к мнению, что объединение было плохой идеей, просто
        отказаться от него, отменив локальные изменения командой
        <command>svn revert</command>.</para>

      <!-- @ENGLISH {{{
      <para>But assuming that you've reviewed the merged change, you can
        <command>svn commit</command> the change as usual.  At that
        point, the change has been merged into your repository branch.
        In version control terminology, this act of copying changes
        between branches is commonly called


      <para>When you commit the local modification, make sure your log
        message mentions that you're porting a specific change from
        one branch to another.  For example:</para>
      @ENGLISH }}} -->
      <para>Просмотрев результат объединения исправлений, его можно
        зафиксировать как обычно (<command>svn commit</command>).
        После этого изменения будут внесены в вашу ветку хранилища.
        В терминологии управления версиями такую процедуру копирования
        изменений между ветками обычно называют
        <firstterm>портированием</firstterm> изменений.</para>

      <para>При фиксации локальных изменений убедитесь, что в 
        лог-сообщении упоминается о портировании отдельных изменений
        из одной ветки в другую. Например:</para>

      <screen>
$ svn commit -m "integer.c: ported r344 (spelling fixes) from trunk."
Sending        integer.c
Transmitting file data .
Committed revision 360.
</screen>

      <!-- @ENGLISH {{{
      <para>As you'll see in the next sections, this is a very
        important <quote>best practice</quote> to follow.</para>

      <sidebar>
        <title>Why Not Use Patches Instead?</title>

        <para>A question may be on your mind, especially if you're a
          Unix user: why bother to use <command>svn merge</command> at
          all?  Why not simply use the operating system's
          <command>patch</command> command to accomplish the same job?
          For example:</para>
      @ENGLISH }}} -->
      <para>Как вы увидите в последующих разделах, очень важно следовать
        этой <quote>хорошей практике</quote>.</para>

      <sidebar>
        <title>Почему бы не использовать вместо этого патчи?</title>

        <para>Зачем вообще связываться с <command>svn merge</command>? 
          Этот вопрос может крутиться у вас в голове, особенно
          если вы пользователь Unix:  Почему бы не использовать
          команду операционной системы <command>patch</command> для
          выполнения той же работы? Например:</para>

        <screen>
$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk &gt; patchfile
$ patch -p0  &lt; patchfile
Patching file integer.c using Plan A...
Hunk #1 succeeded at 147.
Hunk #2 succeeded at 164.
Hunk #3 succeeded at 241.
Hunk #4 succeeded at 249.
done
</screen>

        <!-- @ENGLISH {{{
        <para>In this particular case, yes, there really is no
          difference.  But <command>svn merge</command> has special
          abilities that surpass the <command>patch</command> program.
          The file format used by <command>patch</command> is quite
          limited; it's only able to tweak file contents.  There's no
          way to represent changes to <emphasis>trees</emphasis>, such
          as the addition, removal, or renaming of files and
          directories.  If Sally's change had, say, added a new
          directory, the output of <command>svn diff</command>
          wouldn't have mentioned it at all.  <command>svn
          diff</command> only outputs the limited patch-format, so
          there are some ideas it simply can't express.
          <footnote>
            <para>In the future, the Subversion project plans to use
              (or invent) an expanded patch format that describes
              changes in tree structure and properties.</para>
          </footnote>
          The <command>svn merge</command> command, however, can express
          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> это упоминаться не будет.
          Вывод <command>svn diff</command> представляет собой только
          ограниченный патч-формат, он просто не может передать 
          некоторые вещи. <footnote><para>В будущем проект Subversion
          планирует использовать (или изобрести) расширенный формат
          представления различий, который будет передавать изменения в
          структуре дерева файлов и свойств.</para></footnote> Команда
          <command>svn merge</command>, напротив, может передавать
          изменения в структуре файлов и свойств, непосредственно 
          применяя их к рабочей копии.</para>

      </sidebar>

      <!-- @ENGLISH {{{
      <para>A word of warning: while <command>svn diff</command> and
        <command>svn merge</command> are very similar in concept, they
        do have different syntax in many cases.  Be sure to read about
        them in <xref linkend="svn.ref"/> for details, or ask
        <command>svn help</command>.  For example, <command>svn
        merge</command> requires a working-copy path as a target, i.e.
        a place where it should apply the tree-changes.  If the target
        isn't specified, it assumes you are trying to perform one of
        the following common operations:</para>

      <orderedlist>
        <listitem>
          <para>You want to merge directory changes into your current
            working directory.</para>
        </listitem>
        <listitem>
          <para>You want to merge the changes in a specific file into
            a file by the same name which exists in your current working
            directory.</para>
        </listitem>
      </orderedlist>
      @ENGLISH }}} -->
      <para>Небольшое предупреждение: несмотря на то, что <command>svn
        diff</command> и <command>svn merge</command> по сути очень 
        похожи, во многих случаях они используют разный синтаксис.
        Обязательно прочтите об этом в <xref linkend="svn.ref"/>, или
        спросите у <command>svn help</command>. Например, <command>svn
        merge</command> требует в качестве целевого объекта путь в
        рабочей копии, то есть место, где ей нужно применить изменения
        структуры файлов. Если целевой объект не указан, предполагается,
        что делается попытка выполнить одну из следующих операций:</para>

      <orderedlist>
        <listitem>
          <para>объединение изменений каталога с вашим текущим
            рабочим каталогом;</para>
        </listitem>
        <listitem>
          <para>объединение изменений в конкретном файле с
            файлом, имеющим то же имя в текущем рабочем каталоге.</para>
        </listitem>
      </orderedlist>

      <!-- @ENGLISH {{{
      <para>If you are merging a directory and haven't specified a
        target path, <command>svn merge</command> assumes the first case
        above and tries to apply the changes into your current
        directory.  If you are merging a file, and that file (or a file
        by the same name) exists in your current working directory,
        <command>svn merge</command> assumes the second case and tries
        to apply the changes to a local file with the same name.</para>

      <para>If you want changes applied somewhere else, you'll
        need to say so.  For example, if you're sitting in the parent
        directory of your working copy, you'll have to specify the
        target directory to receive the changes:</para>
      @ENGLISH }}} -->
      <para>Если вы объединяете каталог и не указываете целевой путь,
        <command>svn merge</command> предполагает первый из приведенных выше
        вариантов и пытается применить изменения к текущему каталогу.
        Если вы объединяете файл, и при этом файл с таким именем
        есть в текущем рабочем каталоге, <command>svn merge</command>
        подразумевает второй случай и пытается применить изменения
        к локальному файлу с таким же именем.</para>

      <para>Если вы хотите применить изменения к чему-то другому, вам
        нужно это указать. Например, если вы находитесь в родительском
        каталоге рабочей копии, то вам нужно указать целевой каталог,
        получающий изменения:</para>

      <screen>
$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
U   my-calc-branch/integer.c
</screen>

    </sect2>

    <!-- =============================================================== -->
    <sect2 id="svn.branchmerge.copychanges.keyconcept">
      <!-- @ENGLISH {{{
      <title>The Key Concept Behind Merging</title>

      <para>You've now seen an example of the <command>svn
          merge</command> command, and you're about to see several
          more.  If you're feeling confused about exactly how merging
          works, you're not alone.  Many users (especially those new
          to version control) are initially perplexed about the proper
          syntax of the command, and about how and when the feature
          should be used.  But fear not, this command is actually much
          simpler than you think!  There's a very easy technique for
          understanding exactly how <command>svn merge</command>
          behaves.</para>

      <para>The main source of confusion is the
        <emphasis>name</emphasis> of the command.  The term
        <quote>merge</quote> somehow denotes that branches are
        combined together, or that there's some sort of mysterious
        blending of data going on.  That's not the case.  A better
        name for the command might have been <command>svn
        diff-and-apply</command>, because that's all that happens:
        two repository trees are compared, and the differences are
        applied to a working copy.</para>
      @ENGLISH }}} -->
      <title>Ключевые идеи, стоящие за слиянием</title>


      <para>Теперь, после знакомства с примерами использования <command>svn
        merge</command>, настала пора разобраться в них поглубже. 
        Если вы чувствуете неуверенность в том как, собственно, 
        работает слияние, то вы в этом
        вы не одиноки. Многие пользователи (особенно те, для которых
        управление версиями в новинку) поначалу путаются в правильности
        записи этой команды и в том, как и когда эту функцию следует
        использовать. Отбросьте страх &mdash; на самом деле эта команда 
        намного проще, чем вы думаете! Понять, как именно ведет себя 
        <command>svn merge</command>, очень просто.</para>

      <para>В ступор вводит, главным образом,
        <emphasis>название</emphasis> команды. Термин <quote>слияние</quote>
        как бы указывает на то, что ветки соединяются вместе, или
        происходит какое-то волшебное смешивание данных. На самом деле это
        не так. Пожалуй, этой команде лучше бы подощло название <command>svn
        diff-and-apply</command>, поскольку это всё, что в результате 
        происходит: сравниваются два файловых дерева хранилища, а 
        различия переносятся в рабочую копию.</para>

      <!-- @ENGLISH {{{
      <para>The command takes three arguments:</para>

      <orderedlist>

        <listitem><para>An initial repository tree (often called the
        <firstterm>left side</firstterm> of the
        comparison),</para></listitem>

        <listitem><para>A final repository tree (often called the
        <firstterm>right side</firstterm> of the
        comparison),</para></listitem>

        <listitem><para>A working copy to accept the differences as
        local changes (often called the <firstterm>target</firstterm>
        of the merge).</para></listitem>

      </orderedlist>
      @ENGLISH }}} -->
      <para>Команда принимает три аргумента:</para>

      <orderedlist>

        <listitem><para>Начальное дерево хранилища (как правило,
          называемое <firstterm>левой частью</firstterm>
          при сравнении),</para></listitem>

        <listitem><para>Конечное дерево хранилища (как правило
          называемое <firstterm>правой частью</firstterm> при
          сравнении),</para></listitem>

        <listitem><para>Рабочую копию, к которой отличия применяются
          в виде локальных изменений (как правило, называемую
          <firstterm>целью</firstterm> слияния).</para></listitem>

      </orderedlist>

      <!-- @ENGLISH {{{
      <para>Once these three arguments are specified, the two trees
        are compared, and the resulting differences are applied to the
        target working copy as local modifications.  When the command
        is done, the results are no different than if you had
        hand-edited the files, or run various <command>svn
        add</command> or <command>svn delete</command> commands
        yourself.  If you like the results, you can commit them.  If
        you don't like the results, you can simply <command>svn
        revert</command> all of the changes.</para>

      <para>The syntax of <command>svn merge</command> allows you to
        specify the three necessary arguments rather flexibly.  Here
        are some examples:</para>
      @ENGLISH }}} -->
      <para>Когда эти три аргумента указаны, производится сравнение 
        двух деревьев, а полученные различия применяются к целевой 
        рабочей копии в виде локальных изменений. После выполнения 
        этой команды результат будет так же, как в случае, если бы вы 
        вручную редактировали файлы или многократно выполняли команды
        <command>svn add</command> или <command>svn delete</command>. 
        Если результат вас устраивает, его можно
        зафиксировать. Если результат вас не устраивает, просто
        отмените (<command>svn revert</command>) все сделанные
        изменения.</para>

      <para>Синтаксис <command>svn merge</command> позволяет
        указывать эти три аргумента довольно гибко. Вот
        несколько примеров:</para>

      <screen>      
$ svn merge http://svn.example.com/repos/branch1@150 \
            http://svn.example.com/repos/branch2@212 \
            my-working-copy

$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy

$ svn merge -r 100:200 http://svn.example.com/repos/trunk
</screen>

      <!-- @ENGLISH {{{
      <para>The first syntax lays out all three arguments explicitly,
        naming each tree in the form <emphasis>URL@REV</emphasis> and
        naming the working copy target.  The second syntax can be used
        as a shorthand for situations when you're comparing two
        different revisions of the same URL.  The last syntax shows
        how the working-copy argument is optional; if omitted, it
        defaults to the current directory.</para>
      @ENGLISH }}} -->
      <para>В первом варианте все три аргумента указаны явно &mdash;
        каждое дерево задано в форме <emphasis>URL@REV</emphasis> и
        указана целевая рабочая копия. Второй вариант может
        использоваться для краткости записи в ситуациях, когда
        сравниваются две разных правки по одному и тому же URL.
        Последний вариант демонстрирует возможность не указывать целевую
        рабочую копию, при этом по умолчанию используется текущий
        каталог.</para>

    </sect2>

    <!-- =============================================================== -->
    <sect2 id="svn.branchmerge.copychanges.bestprac">
      <!-- @ENGLISH {{{
      <title>Best Practices for Merging</title>

      <sect3 id="svn.branchmerge.copychanges.bestprac.track">
        <title>Tracking Merges Manually</title>

        <para>Merging changes sounds simple enough, but in practice it
          can become a headache.  The problem is that if you
          repeatedly merge changes from one branch to another, you
          might accidentally merge the same change
          <emphasis>twice</emphasis>.  When this happens, sometimes
          things will work fine.  When patching a file, Subversion
          typically notices if the file already has the change, and
          does nothing.  But if the already-existing change has been
          modified in any way, you'll get a conflict.</para>
        @ENGLISH }}} -->
      <title>Как правильнее всего использовать слияние</title>

      <sect3 id="svn.branchmerge.copychanges.bestprac.track">
        <title>Ручной контроль слияния</title>

        <para>На первый взгляд объединить изменения просто, однако
          на практике могут возникнуть трудности. Проблема заключается
          в том, что при многократном объединении изменений одной
          ветки с другой можно непреднамеренно сделать объединение одних
          и тех же изменений <emphasis>дважды</emphasis>. Иногда
          это не вызывает проблем. При применении изменений к файлу 
          Subversion, как правило, предупреждает о том, что файл 
          уже содержит изменения и в этом случае не
          выполняет никаких действий. Однако, если уже присутствующие
          изменения были модифицированы, возникнет конфликт.</para>

        <!-- @ENGLISH {{{
        <para>Ideally, your version control system should prevent the
          double-application of changes to a branch.  It should
          automatically remember which changes a branch has already
          received, and be able to list them for you.  It should use
          this information to help automate merges as much as
          possible.</para>

        <para>Unfortunately, Subversion is not such a system.  Like
          CVS, Subversion does not yet record any information about
          merge operations.  When you commit local modifications, the
          repository has no idea whether those changes came from
          running <command>svn merge</command>, or from just
          hand-editing the files.</para>
        @ENGLISH }}} -->
        <para>В идеале система управления версиями должна предотвращать
          повторное применение изменений к ветке. Она должна автоматически
          фиксировать, какие изменения уже были получены и иметь возможность
          перечислить их вам. Она должна использовать эту информацию 
          для того, чтобы, насколько возможно, помочь автоматизировать
          слияние.</para>

        <para>К сожалению, Subversion не такая система. Как и
          CVS, Subversion пока не сохраняет никакой информации об
          операциях слияния. При фиксации локальных изменений хранилище
          понятия не имеет, являются ли эти изменения результатом
          выполнения команды <command>svn merge</command> или результатом
          обычного ручного редактирования файлов.</para>

        <!-- @ENGLISH {{{
        <para>What does this mean to you, the user?  It means that
          until the day Subversion grows this feature, you'll have to
          track merge information yourself.  The best place to do this
          is in the commit log-message.  As demonstrated in the
          earlier example, it's recommended that your log-message
          mention a specific revision number (or range of revisions)
          that are being merged into your branch.  Later on, you can
          run <command>svn log</command> to review which changes your
          branch already contains.  This will allow you to carefully
          construct a subsequent <command>svn merge</command> command
          that won't be redundant with previously ported
          changes.</para>

        <para>In the next section, we'll show some examples of this
          technique in action.</para>
        @ENGLISH }}} -->
        <para>Что это означает для вас как пользователя? Это означает,
          что до того момента, пока у Subversion не появится этой функции,
          вам придется контролировать слияние информации самостоятельно.
          Лучшим местом для этого является лог-сообщение. Как было
          показано в предыдущих примерах, рекомендуется, чтобы в
          лог-сообщении был указан конкретный номер правки (или диапазон
          правок), которые были слиты в вашу ветку. В этом случае вы 
          сможете впоследствии просмотреть, какие изменения уже содержит
          ваша ветка, запусти команду <command>svn log</command>. Это
          позволит быть осторожнее при последующих запусках команды 
          <command>svn merge</command> и избежать пересечения с уже 
          портированными изменениями.</para>


        <para>В следующем разделе мы на примерах рассмотрим эту методику
          в действии.</para>

      </sect3>

      <sect3 id="svn.branchmerge.copychanges.bestprac.preview">
        <!-- @ENGLISH {{{
        <title>Previewing Merges</title>

        <para>Because merging only results in local modifications,
          it's not usually a high-risk operation.  If you get the
          merge wrong the first time, simply <command>svn
          revert</command> the changes and try again.</para>

        <para>It's possible, however, that your working copy might
          already have local modifications.  The changes applied by a
          merge will be mixed with your pre-existing ones, and running
          <command>svn revert</command> is no longer an option.  The
          two sets of changes may be impossible to separate.</para>
        @ENGLISH }}} -->
        <title>Предварительный просмотр результатов слияния</title>

        <para>Поскольку результатом слияния являются локальные
          изменения, такая операция не является опасной. Допустив
          при слиянии ошибку, можно просто
          отменить изменения (<command>svn revert</command>) и
          попробовать еще раз.</para>

        <para>Однако, возможна ситуация, когда рабочая копия уже
          содержит локальные изменения. Изменения, примененные при
          слиянии, будут смешаны с уже существующими, и запуск
          <command>svn revert</command> нас больше не устроит.
          Разделить два множества изменений будет невозможно.</para>

        <!-- @ENGLISH {{{
        <para>In cases like this, people take comfort in being able to
          predict or examine merges before they happen.  One simple
          way to do that is to run <command>svn diff</command> with
          the same arguments you plan to pass to <command>svn
          merge</command>, as we already showed in our first example
          of merging.  Another method of previewing is to pass the
          <option>-&#64738;-dry-run</option> option to the merge
          command:</para>
        @ENGLISH }}} -->
        <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
U  integer.c

$ svn status
#  nothing printed, working copy is still unchanged.
</screen>

        <!-- @ENGLISH {{{
             <para>The <option>-&#64738;-dry-run</option> option doesn't actually
          apply any local changes to the working copy.  It only shows
          status codes that <emphasis>would</emphasis> be printed in a
          real merge.  It's useful for getting a <quote>high
          level</quote> preview of the potential merge, for those
          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>

      </sect3>

      <sect3 id="svn.branchmerge.copychanges.bestprac.merge">
        <!-- @ENGLISH {{{
        <title>Merge Conflicts</title>

        <para>Just like the <command>svn update</command> command,
          <command>svn merge</command> applies changes to your working
          copy.  And therefore it's also capable of creating
          conflicts.  The conflicts produced by <command>svn
          merge</command>, however, are sometimes different, and this
          section explains those differences.</para>

        <para>To begin with, assume that your working copy has no
          local edits.  When you <command>svn update</command> to a
          particular revision, the changes sent by the server will
          always apply <quote>cleanly</quote> to your working copy.
          The server produces the delta by comparing two trees: a
          virtual snapshot of your working copy, and the revision tree
          you're interested in.  Because the left-hand side of the
          comparison is exactly equal to what you already have, the
          delta is guaranteed to correctly convert your working copy
          into the right-hand tree.</para>
        @ENGLISH }}} -->
        <title>Конфликты при слиянии</title>

        <para>Так же как и <command>svn update</command>, команда
          <command>svn merge</command> внедряет изменения в
          рабочую копию. Следовательно, она тоже может создавать
          конфликты. Однако конфликты, порождаемые <command>svn
          merge</command>, имеют определенные отличия, и поэтому 
          мы их сейчас рассмотрим подробнее.</para>

        <para>Вначале предположим, что рабочая копия не имеет
          локальных изменений. При обновлении (<command>svn
          update</command>) рабочей копии до конкретной правки 
          отправляемые сервером изменения будут всегда <quote>без 
          проблем</quote> внедряться
          в рабочую копию. Сервер создает дельту, сравнивая два дерева:
          виртуальный снимок рабочей копии и дерево файлов, которое
          вас интересует. Учитывая то, что левая часть сравнения
          полностью эквивалентна тому, что вы уже имеете, дельта
          гарантированно правильно конвертирует рабочую копию в правую
          часть сравнения.</para>

        <!-- @ENGLISH {{{
        <para>But <command>svn merge</command> has no such guarantees
          and can be much more chaotic: the user can ask the server to
          compare <emphasis>any</emphasis> two trees at all, even ones
          that are unrelated to the working copy!  This means there's
          large potential for human error.  Users will sometimes
          compare the wrong two trees, creating a delta that doesn't
          apply cleanly.  <command>svn merge</command> will do its
          best to apply as much of the delta as possible, but some
          parts may be impossible.  Just like the Unix
          <command>patch</command> command sometimes complains about
          <quote>failed hunks</quote>, <command>svn merge</command>
          will complain about <quote>skipped targets</quote>:</para>
        @ENGLISH }}} -->
        <para>Однако <command>svn merge</command> не дает такой
          гарантии, и может вести себя более непредсказуемо:
          пользователь может запросить сервер сравнить
          <emphasis>любые</emphasis> два дерева файлов, даже такие,
          которые не имеют отношения к рабочей копии! Из этого
          следует множество потенциальных человеческих
          ошибок. Иногда пользователи будут сравнивать два
          ошибочных дерева, создавая дельту, которая не
          сможет правильно внедриться. <command>svn
          merge</command> будет пытаться внедрить различия
          по максимуму, но иногда это будет невозможно.
          Так же как команда <command>patch</command> в Unix
          иногда жалуется на <quote>неудачные попытки</quote>
          объединения, <command>svn merge</command> будет
          жаловаться на <quote>пропущенные цели</quote>:</para>

        <screen>
$ svn merge -r 1288:1351 http://svn.example.com/repos/branch
U  foo.c
U  bar.c
Skipped missing target: 'baz.c'
U  glub.c
C  glorb.h

$
</screen>

        <!-- @ENGLISH {{{
        <para>In the previous example it might be the case that
          <filename>baz.c</filename> exists in both snapshots of the
          branch being compared, and the resulting delta wants to
          change the file's contents, but the file doesn't exist in
          the working copy.  Whatever the case, the
          <quote>skipped</quote> message means that the user is most
          likely comparing the wrong two trees; they're the classic
          sign of driver error.  When this happens, it's easy to
          recursively revert all the changes created by the merge
          (<command>svn revert -&#64738;-recursive</command>), delete any
          unversioned files or directories left behind after the
          revert, and re-run <command>svn merge</command> with
          different arguments.</para>

        <para>Also notice that the previous example shows a conflict
          happening on <filename>glorb.h</filename>.  We already
          stated that the working copy has no local edits: how can a
          conflict possibly happen?  Again, because the user can use
          <command>svn merge</command> to define and apply any old
          delta to the working copy, that delta may contain textual
          changes that don't cleanly apply to a working file, even if
          the file has no local modifications.</para>
        @ENGLISH }}} -->
        <para>Возможно, что в предыдущем примере файл
          <filename>baz.c</filename> существует в обоих сравниваемых
          снимках ветки и Subversion пытается применить результирующую
          дельту для того, чтобы изменить содержимое файла, однако в
          рабочей копии файл отсутствует. В любом случае сообщение
          <quote>skipped</quote> означает, что скорее всего пользователь
          ошибся при указании деревьев для сравнения &mdash; то есть это 
          классическая ошибка оператора. Если это так, проще 
          всего рекурсивно отменить все изменения, сделанные при слиянии 
          (<command>svn revert --recursive</command>), сразу же после 
          этого удалить все неверсионированные файлы и каталоги и 
          повторно запустить <command>svn merge</command> с 
          другими параметрами.</para>


        <para>Обратите внимание на то, что в предыдущем примере
          в файле <filename>glorb.h</filename> возник конфликт.
          Откуда же он мог взяться, если ранее мы договорились, 
          что рабочая копия не имеет локальных изменений?
          Опять же, пользователь мог запустить <command>svn
          merge</command> для выделения и применения к рабочей копии
          какой то старой дельты. В результате такая дельта может
          содержать изменения, которые нельзя внедрить в рабочий
          файл без появления проблем, даже если он не имеет локальных
          изменений.</para>

        <!-- @ENGLISH {{{
        <para>Another small difference between <command>svn
          update</command> and <command>svn merge</command> are the
          names of the full-text files created when a conflict
          happens.  In <xref linkend="svn.tour.cycle.resolve"/>, we saw
          that an update produces files named
          <filename>filename.mine</filename>,
          <filename>filename.rOLDREV</filename>, and
          <filename>filename.rNEWREV</filename>.  When <command>svn
          merge</command> produces a conflict, though, it creates
          three files named <filename>filename.working</filename>,
          <filename>filename.left</filename>, and
          <filename>filename.right</filename>.  In this case, the
          terms <quote>left</quote> and <quote>right</quote> are
          describing which side of the double-tree comparison the file
          came from.  In any case, these differing names will help you
          distinguish between conflicts that happened as a result of an
          update versus ones that happened as a result of a
          merge.</para>
        @ENGLISH }}} -->
        <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.rNEWREV</filename>. А <command>svn
          merge</command> в конфликтной ситуации создает три файла
          с названиями <filename>filename.working</filename>,
          <filename>filename.left</filename> и
          <filename>filename.right</filename>. Термины 
          <quote>left</quote> и <quote>right</quote> указывают здесь
          на две стороны сравнения, то есть на используемые при
          сравнении деревья. Это разделение используемых названий
          поможет вам отличать конфликты, возникшие в результате
          обновления, от конфликтов, возникших в результате
          слияния.</para>

      </sect3>

      <sect3 id="svn.branchmerge.copychanges.bestprac.ancestry">
        <!-- @ENGLISH {{{
        <title>Noticing or Ignoring Ancestry</title>

        <para>When conversing with a Subversion developer, you might
          very likely hear reference to the term
          <firstterm>ancestry</firstterm>.  This word is used to
          describe the relationship between two objects in a
          repository: if they're related to each other, then one
          object is said to be an ancestor of the other.</para>

        <para>For example, suppose you commit revision 100, which
          includes a change to a file <filename>foo.c</filename>.
          Then <filename>foo.c@99</filename> is an
          <quote>ancestor</quote> of <filename>foo.c@100</filename>.
          On the other hand, suppose you commit the deletion of
          <filename>foo.c</filename> in revision 101, and then add a
          new file by the same name in revision 102.  In this case,
          <filename>foo.c@99</filename> and
          <filename>foo.c@102</filename> may appear to be related
          (they have the same path), but in fact are completely
          different objects in the repository.  They share no history
          or <quote>ancestry</quote>.</para>
        @ENGLISH }}} -->
        <title>Учитывать или игнорировать происхождение</title>

        <para>Общаясь с разработчиками, использующими Subversion,
          очень часто можно услышать термин
          <firstterm>происхождение</firstterm>. Это слово используется
          для описания отношений между двумя объектами хранилища:
          если между ними есть связь, то говорят, что один объект
          происходит от другого.</para>

        <para>Предположим, что фиксируется правка 100,
          в которой изменяется файл <filename>foo.c</filename>.
          В этом случае файл <filename>foo.c@99</filename> является предком
          файла <filename>foo.c@100</filename>. С другой стороны, можно
          допустить, что в правке 101 вы фиксируете удаление
          <filename>foo.c</filename>, а затем в правке 102 добавляете
          новый файл с таким же именем. В таком случае может показаться,
          что файлы <filename>foo.c@99</filename> и <filename>foo.c@102</filename>
          имеют отношение друг к другу (у них одинаковый путь), 
          однако на самом деле они являются
          полностью независимыми объектами хранилища. Они не имеют
          ни общей истории, ни общих <quote>предков</quote>.</para>

        <!-- @ENGLISH {{{
        <para>The reason for bringing this up is to point out an
          important difference between <command>svn diff</command> and
          <command>svn merge</command>.  The former command ignores
          ancestry, while the latter command is quite sensitive to it.
          For example, if you asked <command>svn diff</command> to
          compare revisions 99 and 102 of <filename>foo.c</filename>,
          you would see line-based diffs; the <literal>diff</literal>
          command is blindly comparing two paths.  But if you asked
          <command>svn merge</command> to compare the same two objects,
          it would notice that they're unrelated and first attempt to
          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>
          и <command>svn merge</command>. Первая команда игнорирует
          происхождение, в то время как вторая его учитывает.
          Например, если попросить <command>svn diff</command> сравнить
          правки 99 и 102 файла <filename>foo.c</filename> вы увидите
          построчное сравнение; команда <literal>diff</literal> слепо сравнивает
          два пути. А вот если вы попросите <command>svn merge</command>
          сравнить те же объекты, то Subversion предупредит вас о том, что
          они не связаны друг с другом и сначала попытается удалить
          старый файл, а затем добавить новый; вывод команды покажет
          удаление с последующим добавлением:</para>

        <screen>
D  foo.c
A  foo.c
</screen>

        <!-- @ENGLISH {{{