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

Содержание 1 Управление и контроль 1.1 Клиент–сервер против распределенки 1.2 Bazaar 1.2.1 Работа оффлайн 1.3 Subversion 1.3.1 Разрешение конфликтов 1.3.2 Маркировка изменений 1.4 Git 1.4.1 Совместимость 1.4.2 Хук слева, хук справа 1.5 Вердикт

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

Джульетта Кемп оценивает трех главных претендентов на должность менеджера изменений в ваших данных: 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, поддерживаются «хуки» (скрипты, исполняемые по поводу определенных событий). Это может пригодиться, например, для тестовой сборки кода перед фиксацией изменений в репозитории; для удаления лишних пробелов; для замены пробелов на знаки табуляции или наоборот; для отправки электронных сообщений коллегам по случаю фиксации новых файлов. И вообще для выполнения любой задачи, на которую у вас хватит воображения и способностей к скриптописанию!

Git

Чрезвычайно распределенная, и очень быстрая.

• Сайт http://git-scm.com
• Лицензия GPL
• Применяется в ядре Linux, Gnome, Perl, X.org, VLC, Android

Как и Bazaar, Git – это вариант распределенной СКВ; изначально она была создана Линусом Торвальдсом [Linus Torvalds] для ядра Linux.

Одна из ключевых особенностей Git – поддержка нелинейного процесса разработки: идея состоит в том, что изменения вливаются неоднократно, по мере проверок ответственными лицами (именно так и происходит развитие Linux). На практике это значит очень простое слияние ветвей и деревьев, даже если они никак не связаны между собой и не имеют общих предков. Можно даже встраивать код неопределенной версии в существующее версионное дерево: на такие фокусы не способны ни Bazaar, ни Subversion. Кроме того, в Git значительное внимание уделяется скорости, быстроте работы с крупными проектами.

Распределенная природа позволяет Git, как и Bazaar, сопровождать каждую рабочую копию отдельным репозиторием (в подкаталоге .git), а не полагаться на одно централизованное хранилище, как делает SVN. Кроме того, в этой системе несложно создать новый проект – нужно лишь дать команды git init; git add.; git commit в его каталоге. Это, правда, немного осложняет резервное копирование. Ну, а при желании всегда можно создать собственный вариант локального централизованного репозитория.

Совместимость

Как и Bazaar, Git работает с Subversion: можно пользоваться репозиторием Subversion непосредственно в Git с помощью команды git-svn. Это очень полезно, если, например, вы хотите просто попробовать систему или работаете с проектом SVN, изменять который не следует. При сильном сходстве, команды имеют и отличия от тех, что используются в Bazaar и Subversion. Есть действительно классные улучшения: например, git diff автоматически использует в качестве пейджера команду less, и вам незачем помнить о соединении процессов через канал.

Также интересно обеспечение безопасности: история записывается таким образом, что номера версий зависят от ранее сделанных изменений. После публикации версии исправить ее тайком невозможно.

На практике версии распознаются по идентификатору SHA1 ID, 160‑битному числу в шестнадцатеричном формате. Естественный недостаток этого способа – длинный и сложный номер. Впрочем, в Git есть автодополнение, да и копирование-вставку никто не отменял.

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

В отличие от манеры Subversion, при слиянии сохраняется полная история изменений обеих ветвей; кроме того, ветви можно сливать многократно. Основной приоритет в Git отдан гибкости и возможности многократного слияния различных ветвей разного происхождения. Система работает с патчами (пакетами изменений) и обладает развитой поддержкой патчей, доставляемых по электронной почте. Вы можете просто указать программе на почтовый ящик (в формате mailbox), содержащий сообщения с патчами: они будут извлечены и пущены в дело. А для работы с группами патчей еще есть инструмент StGIT.

Хук слева, хук справа

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

Вердикт

Все три рассмотренные системы управления версиями – замечательные экземпляры ПО: ваш выбор зависит от ваших же потребностей.

При сверхраспределенной схеме разработки, с большим количеством независимо работающих программистов, Git обладает рядом несомненных преимуществ. Для действующих в одиночку использование распределенной системы тоже имеет смысл, ведь в этом случае так просто создать новый репозиторий (даже из существующего каталога). А ведь чем проще пользоваться системой, тем выше вероятность ее выбора. Только не забывайте о регулярном резервном копировании!

Для более централизованных проектов лучше подходит Subversion – поддержка для этой системы тоже неплохая. Bazaar служит мостиком между централизованными и распределенными системами: несмотря на распределенную природу, в этой системе можно вести и более централизованную работу (если такая вдруг понадобится).

К счастью, затраты на эксперименты со всеми тремя вариантами (особенно распределенными) невысоки: просто возьмите себе экземпляр, да и попробуйте. Не понравится – можно потом перейти на другую систему. LXF