LXF120:Контроль версий

Материал из Linuxformat.

Версия 06:37, 23 июня 2010

Управление и контроль

Джульетта Кемп оценивает трех главных претендентов на должность менеджера изменений в ваших данных: Bazaar, Subversion и Git.

Системы контроля версий (СКВ) необходимы при коллективной работе над проектами, но весьма полезны и для предпочитающих сольную деятельность. Отслеживание сделанных изменений обеспечит вам откат к одной из прежних версий, если вы случайно что-нибудь испортите.

Со времени выхода устаревшей CVS появилось множество новых вариантов – какой же из них предпочесть? Распределенную систему или централизованную? Мы рассмотрим самые известные реализации – Bazaar, Subversion и Git, чтобы вы осознанно выбрали наиболее подходящую именно вашим нуждам, будь это крупный проект, любительское программирование, отслеживание изменений в конфигурационных файлах или что-нибудь более экзотичное.

Клиент–сервер против распределенки

Существует два основных типа систем контроля версий: клиент– серверные и распределенные. Бывают и чисто локальные системы, типа RCS, которые действуют исключительно в рамках одной машины, но сейчас они применяются редко: иметь дело с современными разновидностями в любом случае и проще, и удобнее.

Клиент–серверные системы работают в централизованном режиме: на центральном сервере существует текущая копия проекта, из которой «выписывает» (‘checkout’) данные локально работающий пользователь. Внеся желаемые изменения, он (или она) обновляет локальную копию с сервера (чтобы учесть изменения, которые успели сделать за это время другие пользователи), разрешает конфликты, если таковые возникают, а затем фиксирует (‘commit’) свою версию данных в центральном репозитории. После этого внесенные изменения становятся доступны для выписки другими людьми.

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

Оба варианта имеют и достоинства, и недостатки. Вот некоторые из преимуществ распределенных СКВ:

• Обеспечивается полное резервное копирование кодовой базы и истории изменений для каждой ветви проекта; возможно существование нескольких ветвей.
• Упрощается работа без подключения к Интернету, так как изменения можно до поры фиксировать в локальном хранилище.
• Проще взаимодействовать с коллегами: для этого не нужно обращаться к централизованной системе.
• Легче создавать и ликвидировать ветви разработки: тем самым упрощается проведение экспериментов в ходе развития проекта.
• Есть мнение, что такой способ более демократичен, и позволяет вовлекать в проекты большее число участников.
• Можно организовать несколько «центральных» ветвей с различной специализацией (например, стабильную, текущую и релиз).
• Фиксация изменений, просмотр истории и другие подобные операции происходят быстрее: для них не нужен доступ к центральному серверу.
• Упрощается слияние нескольких частей проекта.

Централизованные СКВ тоже обладают рядом достоинств:

• Любой отдельный пользователь или группа может получить полный доступ к истории и содержанию проекта (правда, иногда это достоинство может рассматриваться как недостаток!).
• Главная версия кода содержится централизованно, а не дробится на несколько вариантов.
• Проще обеспечить отказоустойчивость одного централизованного сервера (хотя бы за счет квалифицированного обслуживания), чем множества пользовательских персональных машин.

Короче, внимания заслуживают оба варианта, хотя в наши дни популярность набирают именно распределенные системы.

Bazaar

Распределенная система не без способностей к централизации.

• Сайт http://bazaar-vcs.org
• Лицензия GPL
• Применяется в MySQL, Gnash, Squid

Bazaar (в командной строке – bzr) – распределенная система, называемая авторами «СКВ, задуманной для людей». Она рассчитана на поддержку рабочих процессов разнообразных типов и предоставляет вам значительную свободу в выборе способа работы и управления версиями. Возможно использование Bazaar совместно с другими аналогичными системами (например, CVS или Subversion).

Применяя Bazaar в распределенном сценарии, вы создаете по ветви на каждую новую функцию (их называют ‘task branches’ – ветви для задачи), а для отправки изменений на сервер используется локальная ветвь-зеркало. В централизованной модели изменения периодически отправляются непосредственно на общий сервер. Девиз команды разработчиков Bazaar – «не стоит прогибаться под причуды ПО, пускай ПО прогнется под вас».

Одна из приятных особенностей Bazaar – работая индивидуально, вы не должны (как в Subversion, например) создавать репозиторий, импортировать файлы, а потом выписывать рабочую копию. Вы работаете себе в каталоге проекта, а Bazaar сам отслеживает сделанные изменения. Одно из очевидных неудобств – усложнение резервного копирования: следует либо держать все проекты внутри главного каталога, либо обеспечить регулярное сохранение абсолютно всех каталогов (кстати, идея сама по себе неплохая). Кроме того, ненароком ошибившись в команде rm -rf, легко сгубить репозиторий. Начать проект очень просто: вместо импорта и последующей выписки кода достаточно инициализировать проект внутри его собственного каталога. При желании работать в более централизованном режиме можно создать репозиторий в отдельном каталоге и выписать ветвь из него. Это делается всего лишь одной командой: init-repo.

Работа оффлайн

Распределенная природа Bazaar позволяет работать и вносить изменения, не подключаясь к Сети. В централизованных системах это тоже возможно с помощью локального репозитория, но его совмещение с основным сервером чревато сложностями. В Bazaar локальный контроль версий весьма удобен: вы загружаете основной проект командой bzr branch, и на вашей машине создается его локальная ветвь. Можно работать внутри нее, а можно создавать подветви и фиксировать изменения в них с той частотой, какая вам заблагорассудится. Команда bzr merge сольет вашу ветвь проекта с родительской, а завершив работу над кодом, нетрудно создать заплатку для отправки «наверх» командой bzr send -o patchname.patch. Ответственный за родительскую ветвь проекта может внести в нее ваш патч – а может и не внести; для этого используются те же команды, что и при слиянии ветвей. Теоретически Bazaar может обходиться без центрального дерева, но на практике большинство проектов имеют такое и сливают с ним отдельные ветви.

Алгоритм объединения ветвей Bazaar позволяет осуществлять множественное слияние, а также определять последнего общего предка ветвей. Возможно не только объединение, но и «сплетение» различных ветвей, а также разрешение весьма непростых конфликтных ситуаций. Но требование общего предка у ветвей является обязательным (а вот Git умеет совмещать совершенно не родственные ветви).

Bazaar поддерживает выборочное слияние, при котором проводится не полное, а частичное совмещение изменений ветви (например, только до версии 104, или только из версий 105–107). Есть возможность отложить свои изменения до поры, изъяв их из рабочего дерева (например, чтобы упростить слияние с крупным обновлением, произошедшим в родительской ветви), а затем вернуть в проект. Это удобно, если вы работаете над несколькими заплатками, либо хотите воспользоваться правками коллег. Как и в Subversion, можно применять «хуки» (‘hooks’; это скрипты, исполняемые перед определенными действиями или после них).

Полезное качество для крупных проектов – интеграция с системами отслеживания ошибок. С помощью ключа --fixes можно привязать к изменению номер ошибки в системах разных типов (поддерживаются Bugzilla, Launchpad, Trac, Roundup и пр.). Например, строка:

bzr commit -- fixes project:23400 -m «Stores user birthdates properly»

добавит в журнал ссылку на ошибку № 23400 трекера Bugzilla для проекта project. Для Bugzilla и Trac поддерживаются упрощенные режимы настройки.

Subversion

Централизованная система, призванная устранить часть проблем CVS.

• Сайт http://subversion.tigris.org
• Лицензия Apache License
• Применяется в KDE, Python, Ruby, Mono, Google Code

Subversion создавалась на смену популярной CVS, чтобы ликвидировать самые заметные недостатки предшественницы. Как и CVS, система работает в режиме клиент–сервер. Центральный репозиторий может быть локальным (доступ через file://) или удаленным (доступ через http://, https:// или собственные протоколы svn:// и svn+ssh://).

В отличие от Bazaar, здесь перед началом работы необходимо создать центральный репозиторий (локальный или удаленный); поэтому процесс передачи файлов под контроль системы чуть более трудоемок. Покончив с ним, вы заново выписываете данные из репозитория, чтобы получить копию для дальнейшей работы.

Что касается цикла «изменение/проверка/фиксация» (внесение правок в файл, проверка на отсутствие конфликтов и отсылка изменений на сервер), команды и основные операции те же, что применяются в большинстве систем управления версиями. В принципе, начав работу с одной из них, вы получаете ключ ко всем остальным: их команды очень схожи между собой.

Разрешение конфликтов

Если в Subversion вы сталкиваетесь с конфликтом, то перед отправкой вашего файла необходимо явно пометить его как разрешенный (‘resolved’). Иногда это кажется нудным, зато предотвращает случайное попадание конфликтных данных в репозиторий (впрочем, ничто не мешает попросту снять галочку вместо реального разрешения конфликта!).

Репозитории могут иметь ветви и тэги, и слить ветвь с основным кодом (обычно называемым ‘trunk’ – «ствол») достаточно легко. Однако многоуровневое ветвление или перекрестные связи между ветвями осуществляются «со скрипом» – с такими выкрутасами распределенные системы справляются гораздо лучше.

Можно сливать или разделять репозитории целиком – инструмент администратора SVN под названием svndumpfilter позволяет обрабатывать проекты с помощью фильтра. И все-таки Subversion недоступен присущий распределенным системам уровень гибкости и эффективности в работе с ветвями. Не существует встроенных команд, позволяющих взять патч и встроить его в дерево проекта; это можно делать с помощью внешней команды patch, но возможны проблемы с удаленными или слитыми файлами.

Маркировка изменений=

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

$ svn propset test «test property value» myfile.txt
$ svn proplist myfile.txt
Properties on 'myfile.txt'
test
$ svn propget test myfile.txt
test property value

Есть некоторые специальные свойства, названия которых начинаются с svn: – этот префикс здесь находится «на особом положении». Например, если установить для какого-либо файла свойство svn:ignore, то он будет игнорироваться системой.

Как и в Bazaar или Git, поддерживаются «хуки» (скрипты, исполняемые по поводу определенных событий). Это может пригодиться, например, для тестовой сборки кода перед фиксацией изменений в репозитории; для удаления лишних пробелов; для замены пробелов на знаки табуляции или наоборот; для отправки электронных сообщений коллегам по случаю фиксации новых файлов. И вообще для выполнения любой задачи, на которую у вас хватит воображения и способностей к скриптописанию!