Заключительное слово об истории

В дополнение ко всем упомянутым выше командам, можно воспользоваться svn update и svn checkout с параметром --revision, чтобы переместить рабочую копию «назад во времени»^[12]:

$ svn checkout --revision 1729 # Checks out a new working copy at r1729

…

$ svn update --revision 1729 # Updates an existing working copy to r1729

…

3. Ветвление и слияние

Ветвление, назначение меток и слияние — это понятия, свойственные практически всем системам управления версиями. Если вы плохо знакомы с этими понятиями, то в этой главе вы с ними обстоятельно познакомитесь. Если эти понятия вам уже знакомы, то мы надеемся, что вам будет интересно узнать, как эти идеи реализованы в Subversion.

Ветвление — фундаментальное понятие управления версиями. Если вы собираетесь доверить Subversion управление своей информацией, то это именно та функция, от которой вы впоследствии будете сильно зависеть.

3.1 Что такое ветка?

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

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

Чаще всего вам придется вносить изменения в обе копии. Например, если вы обнаружите опечатку в одной копии, скорее всего, эта же опечатка будет присутствовать и в другой. Два документа, в общем-то, почти одинаковы — их различия сводятся к отдельным специфичным моментам.

В этом заключается основная идея ветки — то есть направления разработки, которое существует независимо от другого направления, но имеет с ним общую историю, если заглянуть немного в прошлое. Ветка всегда берет начало как копия чего-либо и движется от этой точки, создавая свою собственную историю (см. Рисунок 4.1, «Ветки разработки»).

Рисунок 4.1. Ветки разработки

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

3.2 Использование веток

К этому моменту вы должны понимать, что в хранилище при каждой фиксации создается полностью новое дерево файлов (называемое «правка»). Если нет, то вернитесь назад и прочитайте о правках в разделе  «Правки».

В этой главе мы воспользуемся тем же примером, что и в Глава 1, Фундаментальные понятия. Как вы помните, вы и ваш соразработчик Салли совместно используете хранилище, содержащее два проекта, paint и calc. Как отмечалось в Рисунок 4.2, «Начальная структура хранилища», каждый каталог проекта содержит подкаталоги с именами trunk и branches. Назначение этих каталогов вскоре станет понятно.

Рисунок 4.2. Начальная структура хранилища

Как и раньше, предположим, что и Салли, и вы имеете рабочие копии проекта «calc». Точнее, каждый из вас имеет рабочую копию /calc/trunk. Все файлы, относящиеся к проекту, находятся в этом подкаталоге, а не прямо в /calc, потому что ваша команда решила размещать «главную линию» разработки в/calc/trunk.

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

Одним из вариантов является временная изоляция: вы и Салли перестаете делиться информацией на неделю или две. В это время вы начинаете перелопачивать и реорганизовывать файлы рабочей копии, но не фиксируете и не обновляете ее до завершения работы над задачей. Однако, в этом случае появляется несколько проблем. Во-первых, это не очень надежно. Большинство людей предпочитают часто сохранять свою работу в хранилище на случай, если с рабочей копией вдруг случится что-то плохое. Во-вторых, это не достаточно гибко. Если вы работаете на разных компьютерах (к примеру, если рабочая копия /calc/trunk есть у вас на двух разных машинах), вам придется вручную копировать изменения туда и обратно, либо делать всю работу на одном компьютере. С другой стороны, вам трудно делиться вносимыми изменениями с кем-то еще. А предоставление возможности знакомиться с проделанной вами работой по мере ее продвижения считается «наилучшей практикой» при разработке любого программного обеспечения. Если никто не будет видеть ваших промежуточных фиксаций, вы теряете потенциал обратной связи. Наконец, когда вы закончите свои изменения, может выясниться, что слить проделанную вами работу с остальным программным кодом компании чрезвычайно трудно. Салли (или кто-то другой) могла внести такие изменения в хранилище, которые трудно совместить с вашей рабочей копией — особенно, если вы выполните svn update впервые после нескольких недель изоляции.

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