Работа с svn из bzr

Юра Юревич подбил меня недавно на пост про то, как я пользуюсь Subversion из Bazaar. Недавно Bazaar поменял мажорную версию на 2.0, и я решил, что пора.

Предыстория такова. В Яндексе много кода (бо́льшая часть наверное) хранится под управлением svn. Подозреваю, что мы не одни такие :-). Какое-то время назад меня стало точить настойчивое желание попользоваться или даже совсем переехать на какую-нибудь распределённую VCS. Волею случая выбор пал на bzr, я его попробовал, и вроде понравилось. Но на работе большую часть времени сидел всё равно под svn, чтобы работать с существующим кодом. Однако совсем недавно я вдруг сложил в голове несколько очевидных вещей, и теперь — тадам! — общаюсь со всем svn-кодом из bzr, используя все прелести последнего.

Теперь делюсь опытом.

Софт

Речь пойдёт о Bazaar версии 2.0.0, к которому нужен плагин bzr-svn версии 1.0. Впрочем, конкретные версии довольно быстро всё равно устареют, поэтому я их упоминаю просто для полноты картины.

Кстати, приятно, что в новой Ubuntu 9.10, выходящей в этом месяце, оба этих пакета именно этих версий есть в главных репозиториях.

svn-import

Первый режим работы с svn — это команда svn-import, которая умеет импортировать svn-репозиторий со всеми бранчами и тегами в самостоятельный bzr-репозиторий. Это однократный импорт, после этого svn-репозиторий можно забыть и пользоваться bzr. Поэтому это, пожалуй, всё, что я хочу про неё сказать :-). Интересней другое.

Работа с svn-репозиториями

Самое ценное в bzr-svn — это то, что он добавляет формат subversion'а в качестве ещё одного формата репозитория, известного bzr. И дальше с ним можно работать bzr'ными средствами, практически как с родным. И это идеальный режим, если вы хотите просто попробовать новую VCS:

• коллеги, которые не разделяют ваших экспериментов, продолжают работать с svn, и ваша работа для них выглядит вполне ожидаемо
• если вдруг не понравится, можно вернуться обратно на svn

Вот как это выглядит:

bzr co http://sever/project # чекаут проекта
cd project # перейдя в директорию, можно в ней работать
bzr stat # посмотреть изменения
bzr commit # скоммитить
bzr up # проапдейтить
bzr log --limit 5 # посмотреть последние 5 ревизий

На этом месте некоторые особенно опытные пользователи svn обычно начинают видеть кое-какую общность в поведении bzr и svn. И так оно и есть! Bazaar намеренно копирует интерфейс Subversion до той степени, которой может, именно для того, чтобы люди, к нему привыкшие, могли комфортно работать.

То есть bzr можно фактически использовать просто как svn-клиент. И хотя в этом случае вы фактически не работаете с ним, как с децентрализованной VCS, даже в таком виде работать с ним удобней, чем с svn. Вот некоторые примеры мелких удобств, что первые пришли в голову:

• bzr stat, bzr commit, bzr revert работают по умолчанию для всего дерева, где бы вы внутри него не находились
• bzr commit не даёт закоммитить изменения, если ваша ревизия не последняя (svn в этом случае ругается, только если вы меняете уже изменённые файлы)
• bzr commit в случае неудачи коммита не заставляет вас заново писать коммит-сообщение (или использовать -F commit.tmp), потому что сообщение вы пишете после того, как он убеждается, что коммитить можно
• bzr revert не требует явного указания директории и -R для рекурсии
• bzr stat и bzr log выглядят информативнее
• bzr add автоматически добавляет недобавленные новые файлы в репозитории без явных указаний
• удалённые файлы при коммитах автоматически считаются удалёнными без явного bzr rm
• bzr mv --auto умеет автоматически определять сделанные переименования
• у bzr есть плагины, среди которых например bzrtools, в котором есть команда shelve для временного исключния из коммита "левых" изменений (например нашли орфографическую ошибку, и хотите её закоммитить отдельно, чтобы не мешалась в общем diff'е).

И есть ещё куча других мелочей...

Есть, впрочем, и не столь приятные неожиданности, к которым надо быть готовыми:

• Первичный bzr co вытаскивает к вам не последнюю ревизию, а всю историю ревизий. Поэтому, если у вас большой репозиторий, это будет долго. Но лучше это всё таки один разок пережить, потому что иметь локальную историю очень полезно в будущем.

• Гораздо быстрее работать с svn-репозиториями по ssh, чем по http. Поэтому, если вы можете это настроить — сделайте. При этом адресоваться он будет как bzr co svn+ssh://.... Кстати, и сам svn тоже быстрее работает с репозиториями через такое соединение.

• Базар пока не поддерживает svn:externals. Мы пока у нас обходимся тем, что копируем внешние деревья прямо в проект.

DVCS

Однако самый смак от использования Базара — это использование его как DVCS, а не как svn-клиента.

Базарный checkout — это не то же самое, что svn'овый. Внутри он представляет собой полноценный локальный бранч в собственном формате Базара, плюс живые рабочие файлы, которые можно править ("working tree" в терминах Базара). Также этот бранч жёстко связан с svn'овым репозиторием, и именно поэтому команды bzr up и bzr commit выглядят так, что работают сразу на нём: внутри они неявно вызывают синхронизацию локального бранча со связанным удалённым. В терминах Базара такой бранч называют "mirror branch".

И это, собственно, то, почему напрямую работать с файлами этого бранча не всегда удобно: суть всех DVCS обычно в том, что разработка происходит не в одном месте, а во многих разных. Поэтому работа обычно строится так, что от основного mirror-бранча плодятся новые локальные бранчи на каждый чих. Они уже отвязаны от центрального репозитория, в них можно творить всё, что душе угодно, а потом уже вливать обратно в mirror, откуда изменения будут попадать в svn.

Вот простой пример того, как происходит разработка новой фичи:

cd .. # # перешли в директорию над project
bzr branch project feature # отбранчили новую директорию feature
cd feature

# сделали изменения
bzr commit # коммит локален и делается так часто, как того надо

cd ../project
bzr up # обновимся из svn, чтобы работать на новом коде
bzr merge ../feature # влили все изменения из feature в mirror
# merge сообщает, были ли конфликты. 
# Если есть, исправляем (см. bzr conflicts, bzr resolve, bzr resolved)

bzr commit # вся работа бранча коммитится в mirror и тут же едет в svn

Тут стоит заметить, что все изменения в бранче попадут в svn в виде единого коммита, без подробной истории того, что вы делали в feature-бранче. Это универсально, и обычно это всех устраивает. Однако есть возможность перетащить весь бранч в trunk с сохранением своей истории, ревизия за ревизией. Это конечно возможно, только если trunk с тех пор не уехал куда-нибудь в другую сторону стараниями других разработчиков. Чтобы так сделать, надо в команде merge указать ключик --pull. Он попробует перелить историю, и в этом случае не надо будет даже ничего коммитить, потому что если бранчи не разъехались, то конфликтов не будет по определению. Если же разъехались, то он отработает, как обычный merge, требуя посмотреть глазками на корректность изменений и скоммитить.

Leap of faith

История рефакторинга. Джон Арбаш Майнел.

Здесь как раз проходит так граница, до которой пользователи svn обычно не понимают, зачем это всё надо, а после которой пользователи DVCS уже не понимают, как можно возвращаться обратно к централизованной работе :-).

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

Также вы получаете такие продвинутые вещи, как, например, uncommit, который умеет откручивать текущий бранч назад, оставляя тем не менее доступными "открученные" ревизии.

"Чёрт, надо было бранчиться!"

Ещё один пример гибкости Базара, который очень помогает в начале пути.

Идея делать бранч на каждый чих обычно довольно радикальна, чтобы сразу к ней привыкнуть. Поэтому часто бывает, что все изменения таки начинаются делаться в mirror-бранче, потому что не кажутся такими уж объёмистыми (мы же конечно слишком круты, чтобы не замутить с плеча какой-нибудь "простенький" рефакторинг). Потом оказывается, что работы там было чуток больше, чем казалось в начале, и вот тут в голову приходит мысль, что неплохо бы было в начале отбранчиться, и сделать три-четыре разных коммита для надёжности, а не вкорячивать всё сразу в живой транк.

С Базаром это можно:

cd project
# начать рефакторинг, сделать толпу изменений, осознать масштаб
bzr branch . ../refactoring # отбранчить таки trunk в отдельный бранч

cd ../refactoring
bzr merge --uncommitted # перетащить все незакоммиченные изменения из транка
bzr revert ../project # вернуть транку статус-кво

Shared repository

Последняя на сегодня фишка :-)

Базарные бранчи могут быть довольно большими: в них ведь лежит вся история. Из-за этого создание новых бранчей может быть довольно накладным процессом как по времени, так и по занимаемому на диске месту. Чтобы с этим бороться, в Базаре есть возможность хранить общие части истории для связанных бранчей один раз, а не копировать. Фактически это то же, что тот же svn делает с бранчами на сервере. Для этого все бранчи одного проекта должны лежать в какой-нибудь одной общей директории, которая и будет тем самым shared repository, хранящим общую историю.

Причём, что меня в своё время очень обрадовало, репозиторий можно создать и после того, как транк выкачан отдельно на диск:

mv project trunk # переименуем счекаутенный mirror-бранч для удобства
mkdir project # теперь project будет именоваться весь репозиторий
cd project
bzr init-repo . # создадим репозиторий
mv ../trunk . # передвинем trunk внутрь репозитория
bzr reconfigure --use-shared trunk # переделать бранч trunk на использование репозитория

С этого момента весь бранчинг внутри директории project автоматически будет дешёвым, используя общий репозиторий.

Другое

Я рассказал о том, как сам использую Базар, но это не единственный способ. Есть много других интересных способов прогибать его под свои нужды. Все основные описаны в документации (с картинками!): Workflows. Выбирайте то, что удобно вам.

Кроме того, порекомендую блог bialix'а "Базарный день", в котором он пишет про всякие интересные внутренности Базара.