3.8 Ключевые идеи, стоящие за слиянием

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

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

Команда принимает три аргумента:

1. Начальное дерево хранилища (как правило, называемое левой частью при сравнении),

2. Конечное дерево хранилища (как правило называемое правой частью при сравнении),

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

Когда эти три аргумента указаны, производится сравнение двух деревьев, а полученные различия применяются к целевой рабочей копии в виде локальных изменений. После выполнения этой команды результат будет так же, как в случае, если бы вы вручную редактировали файлы или многократно выполняли команды svn add или svn delete. Если результат вас устраивает, его можно зафиксировать. Если результат вас не устраивает, просто отмените (svn revert) все сделанные изменения.

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

$ 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

В первом варианте все три аргумента указаны явно — каждое дерево задано в форме URL@REV и указана целевая рабочая копия. Второй вариант может использоваться для краткости записи в ситуациях, когда сравниваются две разных правки по одному и тому же URL. Последний вариант демонстрирует возможность не указывать целевую рабочую копию, при этом по умолчанию используется текущий каталог.

3.9 Как правильнее всего использовать слияние

3.9.1 Ручной контроль слияния

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

В идеале система управления версиями должна предотвращать повторное применение изменений к ветке. Она должна автоматически фиксировать, какие изменения уже были получены и иметь возможность перечислить их вам. Она должна использовать эту информацию для того, чтобы, насколько возможно, помочь автоматизировать слияние.

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

Что это означает для вас как пользователя? Это означает, что до того момента, пока у Subversion не появится этой функции, вам придется контролировать слияние информации самостоятельно. Лучшим местом для этого является лог-сообщение. Как было показано в предыдущих примерах, рекомендуется, чтобы в лог-сообщении был указан конкретный номер правки (или диапазон правок), которые были слиты в вашу ветку. В этом случае вы сможете впоследствии просмотреть, какие изменения уже содержит ваша ветка, запусти команду svn log. Это позволит быть осторожнее при последующих запусках команды svn merge и избежать пересечения с уже портированными изменениями.

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