Журнал LinuxFormat - перейти на главную

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

Материал из Linuxformat
Версия от 10:05, 23 июня 2010; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

Bazaar

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

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.

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

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF120:%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9&oldid=10447»
Персональные инструменты
купить
подписаться
Яндекс.Метрика