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

LXF91:Системы управления версиями

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

Содержание

Системы управления версиями

Git или Bazaar, CVS или Subversion: что лучше для вашего проекта? Выясняет Грэм Моррисон.

Нет сомнения: без систем управления версиями Linux никогда не достиг бы такого расцвета. Управление версиями связывает тысячи разработчиков, собирая сделанное ими и предоставляя результаты остальным. Оно похоже на клей, удерживающий проект в целости и равновесии.


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

Существуют два способа решения этой задачи. В более простом случае для размещения всех файлов проекта используется отдельный сервер. Затем каждый разработчик создает личную копию дерева исходного кода и локально применяет к ней свои изменения, а потом синхронизирует их с данными на сер- вере. Так работают CVS и Subversion, наиболее популярные системы управления версиями.

Путь Торвальдса

Другой подход к совместной работе скорее похож на передачу файлов в пиринговых (peer-to-peer) сетях, чем на разработку приложений. Вместо использования центрального сервера, хранящего все данные проекта, каждый разработчик отвечает за синхронизацию своей рабочей копии проекта с остальными разработчиками. Проект становится децентрализованным. Этот подход, судя по всему, является модной тенденцией, если принять во внимание Git Торвальдса и ряд других систем, успешно применяющих децентрализованное управление версиями.

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

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

RCS

Старейшая система в нашем Сравнении.

Исходная система управления пересмотрами версий (Revision Control System; да-да – RCS и вправду дей- ствует согласно этикетке), может, и вытесняется CVS, но остается популярным выбором в некоторых особых случаях, и есть две главных причины предпочесть RCS более продвинутым решениям. Во-первых, эта система сравнительно проста в использовании и помогает овладеть основными навыками, необходимы- ми для работы в других системах управления пересмотрами версий. Во-вторых, RCS удобна для резервного копирования файлов конфигурации и для ведения небольшой истории откатов (undo/redo). Если вам не понравятся сделанные изменения, очень легко вернуться к более ранней версии.

RCS возвращает нас во времена младенчества совместной разработки ПО, и как таковая предлагает скудный набор функций посравнению с более современными конкурентами. Крупнейший недостаток заключается в том, что RCS умеет работать только с отдельным файлом. Вашей первой мыслью станет: «Ну и что с нее толку?». И верно, из-за своих ограничений RCS – плохой выбор для управления проектом, но случается, что и с отдельным файлом надо поработать, и узконаправленный подход RCS будет более оправдан.

Другое ограничение – в одно и то же время с файлом может работать лишь один разработчик. Один файл, один активный редактор: это не делает RCS самой гибкой системой в мире. Если ваши требования к редактированию отдельного файла выходят за пределы элементарного сотрудничества, ищите дальше.

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


CVS

Второе открытие RCS для тысяч хакеров.

Именно с CVS все становится серьезным. Она была разработана для решения основной проблемы RCS: ограниченности работой с отдельным файлом. Дик Груне [Dick Grune], первоначальный разработчик CVS, нуждался в инструменте для совместной работы над проектом компилятора C с двумя своими студентами, поскольку расписания всех троих резко отличались.

CVS отпочковалась от ранней версии RCS и по-прежнему использует тот же формат файлов для хранения истории каждого отдельного файла. Но запуск команд RCS применительно к CVS-репозиторию может вызвать ряд серьезных проблем, потому что CVS управляет не одним файлом, а целым деревом.

CVS также решает проблему множества пользователей за счет использования клиент-серверной модели. Наличие разработчиков, параллельно работающих над одними и теми же файлами (отсюда и полное имя системы – Concurrent Version System, система управления параллельными версиями) означает, что для обработки изменений CVS нуждается в сервере. Она блокирует файлы, которые изменяются, или предоставляет простой доступ только на чтение. Сервер CVS также способен управлять более чем одним проектом (они хранятся в виде «модулей»). Хотя команды обработки файлов во многом похожи (checkout, update, commit), их теперь нужно исполнять из оболочки CVS, а не из командной строки, как это было в RCS.

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

Aegis

Первая альтернатива клиент-серверной модели.

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

Это – часть крупнейшей проблемы Aegis: трудности использования. Хороший пример - настройка репозитория. Прежде чем приступить к использованию Aegis, вам нужно создать новый проект, содержащий несколько файлов конфигурации. Для этого проекта желательно создать отдельного пользователя, отчасти потому, что модель безопасности Aegis полностью полагается на права доступа к файлам, а отчасти потому, что это обеспечивает приличный уровень безопасности. Для предоставления доступа другим пользователям используются права группы, а значения umask определяют доступ группы к каждому конкретному проекту.

Aegis успешно использует функции Unix, реализованные в любой Linux-системе. Здесь нет интегрированной поддержки совместной работы по сети, но проект можно легко разделять, используя стандартные протоколы типа FTP, HTTP и NFS. Документация даже хвастает поддержкой «беговой сети», когда участники берут ноги в руки и мчатся по коридору к компьютеру, куда нужно скопировать проект. Не слишком удобно для больших расстояний.

Эта сложность отчасти компенсируется документацией хорошего качества, доступной в сети, хотя и в виде плохо отформатированного HTML. Есть несколько графических интерфейсов (использующих Tk) для общих команд, и отличная web-оболочка, но они не конкуренты многим сторонним приложениям, доступным для CVS или Subversion.


Monotone

Система с собственным сетевым протоколом.

Monotone – это управление версиями для нынешнего поколения разработчиков. Здесь нет старых технологий или старого исходного кода. Выбран распределенный подход, без центрального сервера. Вместо этого каждый клиент отвечает за синхронизацию изменений со всеми другими – во многом тем же способом, каким работает протокол предоставления файлов в общий доступ. Он работает за счет сохранения локальной копии каждого изменения в базе данных SQLite и сравнения версий файлов с использованием алгоритма хэширования SHA1.

Установка проста, и полная версия превосходит Aegis. Используя командную строку и команду Monotone, вы сперва создаете базу данных, затем генерируете пару ключей SHA1 для подписывания своих файлов. Пользователям Subversion и CVS покажется очень знакомой работа репозиторием. Команды add (добавле- ние), status (состояние) и commit (фиксация) имеют синтаксис, почти идентичный CVS.

Различие проявляется при слиянии ваших изменений с ветвями разработки других людей. Вам сначала нужно экспортировать свой открытый ключ и получить копию от ваших коллег. Затем они должны импортировать ваш общий ключ в «связку ключей» своего Monotone. После добавления имен коллег в локальный файл разрешений круг доверия замыкается, и вам нужно просто запустить команду server в Monotone. После этого каждый зарегистриро- ванный пользователь сможет синхронизироваться с вашей рабочей копией дерева разработки, используя команду sync. Для копирования данных через интернет или локальную сеть Monotone использует собственный протокол, NetSync. Но поскольку он использует один порт (4691), его довольно легко пробросить через SSH-туннель – чтобы обойти слишком усердные брандмауэры.

Единственный недостаток – отсутствие графических инструментов, помогающих управлять репозиторием. Единственный существующий вариант, Monotone-viz, великолепен для отображения ветвей проекта, но слабо подходит для чего-то еще.

Subversion

Набирающая популярность альтернатива CVS, богатая графическими оболочками.

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

Другая серьезная беда CVS заключается в том, что ‘commit’ не выполняется одним махом, атомарно. Вместо этого он запускается для каждого изменения, насколько это ему удается. Если разработчику случается в это время редактировать файл, значит, ему не повезло. Subversion решает обе эти про- блемы, а также исправляет другие недочеты CVS, например, обеспечивает версионность символических ссылок и реализует поддержку двоичных файлов.

В результате Subversion довольно быстро вытесняет CVS как предпочтительную систему управления версиями, и многие выдающиеся проекты, включая GCC, Samba, Mono, Apache, Python и KDE, переключаются на него для управления исходным кодом.

Без боли

Нет сомнений, что Subversion популярна именно благодаря сходству с CVS. Она использует ту же самую клиент-серверную модель, и основная масса ее команд – двойники команд CVS. Кроме переноса истории версий вашего проекта, переключение с одной системы на другую проходит относительно безболезненно. Зачастую вам может сойти с рук простая замена команды CVS на svn-эквивалент. Установка прямолинейна, и вы найдете пакеты Subversion почти в каждом дистрибутиве Linux, вышедшем за последнюю пару лет. Клиент полезен и сам по себе, а в некоторых случаях он может оказаться единственным способом скачать версии разработчика какого-нибудь интересного вам проекта. Вы также обнаружите изобилие графических интерфейсов, пытающихся сроднить командную строку с преимуществами графических инструментов. Популярный выбор – ksvn для KDE и более общий esvn. Поддержка Subversion также встроена во многие интегрированные среды разработки, включая KDevelop, Eclipse (с расширением Subclipse), Zend Studio и Xcode от Apple.

Что касается доступа к серверу, большинство крупных проектов применяют в этом качестве популярный модуль Apache WebDAV, предоставляющий доступ к web-серверу на чтение-запись.Установить его не слож- но, и раз уж модуль Apache загружен должным образом, настройка тоже дело простое. Вы, скорее всего, обнаружите, что ваш дистрибутив включает этот модуль, заранее скомпилированный для вашей версии Apache. Есть и более простое решение, удобное для небольших групп разработчиков – использовать интегрированный в Subversion протокол SVN, как сам по себе в доверенной сети, так и через SSH-туннель, если ваши коллеги разбросаны по всему Интернету.

Subversion – не самое эффективное ПО для управления версиями. Полная копия репозитория сохраняется в скрытом каталоге, что имеет свое преимущество – можно вносить изменения, когда сеть недоступна – но требует очень много места. База данных истории изменений также может расти экспоненциально, по мере внесения изменений всеми разработчиками, и вам необходимо обеспечить регулярное резервирование базы данных Berkeley. Сценарии резервирования предусмотрены, и они присоединяются к «ловушкам» (hooks). «Ловушки» вызываются определенными событиями, например, внесением изменений (commit) разработчиком, и предоставляют эффективный способ настройки сервера Subversion под ваши нужды.

Благодаря своей повсеместности, Subversion обещает более высокий уровень поддержки сообществом, чем многие другие системы управления пересмотрами. Есть книги, форумы, списки рассылки и свободно публикуемая документация; они помогут вам приступить к работе. Многие проблемы можно решить, скопировав сообщение об ошибке в строку поиска Google, чего нельзя сказать о Monotone или Bazaar. Добавим сюда относительную простоту установки репозитория Subversion или присоединения к открытой разработке, размещенной на другом сервере (как SourceForge, так и Google Code сейчас используют Subversion), и Subversion становится непревзойденной.

Git

Кто сказал, что Линус был сердит?

Даже если вы не интересуетесь программами управления ревизиями, имя Git вам, вероятно, попадалось на том мощном форуме, Slashdot. Git – это еще один плод разума Линуса Торвальса, и появился он со скандалом. В мире «До Git» многие основные разработчики ядра Linux использовали закрытый инструмент управления пересмотрами под названием BitKeeper. Но когда в начале 2005 г. было объявлено об отзыве бесплатной версии BitKeeper, в ответ на поднявшийся в сообществе шум Торвальдс разработал Git. Он объявил, что Git – это вам не просто система управления ревизиями, а скорее усовершенствованная файловая систему. Прежде всего, однако, Git разрабатывался с прицелом на производительность. Когда вы работаете с проектом масштаба ядра Linux, производительность – это все.

Подобно Monotone, Git – распределенная система, без сервера. Но в то же время, в Интернете есть серверы, используемые в качестве центрального репозитория для определенных проектов: прекрасный пример – http://www.kernel.org. Различие между использованием их и чего-то вроде Subversion заключается в том, что если данные на kernel.org будут утрачены, последнюю версию ядра можно будет снова собрать из кода, распределенного среди разработчиков, потому что каждый из них имеет собственную рабочую копию репозитория в подкаталоге .git.

Минуло почти два года, и Git настолько упрочил свои позиции, что вы найдете его либо установленным по умолчанию, либо на расстоянии всего нескольких щелчков мышью в менеджере пакетов каждого свежего дистрибутива Linux. Несмотря на свою репутацию инструмента для хакеров, он сравнительно прост в использовании. Например, репликация удаленного репозитория – это обычно трудоемкая работа. Но в случае с Git это легко. Просто выполните git clone, указав URL удаленного репозитория. Другие коман- ды работают подобно аналогичным функциям в Subversion, и есть прекрасная утилита для обеспечения взаимодействия между двумя системами.

Bazaar

Система управления версиями, спонсируемая Canonical.

Bazaar – наследник распределенной системы управления версиями, Bazaar-NG, возникший благодаря спонсорской поддержке от Canonical Ltd. Неудивительно, что Bazaar используется разработчиками Ubuntu и старается быть как можно более понятным. Хотя он использует распределенную модель, многие из команд очень похожи на команды CVS или Subversion. Поскольку центральный сервер отсутствует, вы заметите различия только когда захотите предоставить в общий доступ свою локальную рабочую копию – вам нужно будет вытянуть (pull) изменения с удаленного репозитория и объединить (merge) со своими изменениями.

Документация великолепна, включая учебники, охватывающие сложные темы, например, отслеживание главной версии и интеграцию с CVS. Базовый учебник даже проводит вас через ряд основных концепций, характерных для всех утилит управления версиями – прекрасный букварь для начинающих. Публикация вашей работы также освежающе проста. Просто скопируйте содержимое свое го рабочего каталога на web-сервер, и другие разработчики смогут забирать копии вашей ветви оттуда. Вы можете синхронизировать ее со своей рабочей копией, используя rsync; в протокол также встроена поддержка SFTP, вызываемая через команду push.

Bazaar использует интерфейс расширений для обеспечения дополнительных функций. Например, несколько графических компонентов на GTK2 можно запускать прямо из командной строки Bazaar. Скажем, ввод bzr visualize откроет визуализатор ветви, который выглядит подобно визуализатору Git. Есть также графические компоненты для команд commit, diff, annotate и branch.

Bazaar трудно не полюбить. У него тот самый разумный подход, который создал популярность Ubuntu, а графические интерфейсы здорово помогают людям, напуганным множеством опций командной строки.

Вердикт

Subversion 9/10

Если честно, мы приступали к этому Сравнению, думая, что это будет игра в одни ворота. Все мы использовали Subversion, были знакомы с тем, как она работает, и в большинстве наших проектов также используется Subversion. Кому ж еще победить?

Что ж, так и вышло, но не с такой легкостью, как мы думали. Распределенные модели, используемые Monotone, Bazaar и Git, удивительно просты в использовании, а отсутствие центрального сервера – реальная инновация. Если бы мы выбирали распределенное решение, это был бы Bazaar. Благодаря раз- работчикам из Canonical, он выглядел самым ухоженным и проработанным из трех. Но и Git, и Monotone удивили нас своим удобством, и в следующие двенадцать месяцев мы можем стать свидетелями захвата ими значительной доли рынка за счет некоторых других систем.

В конечном итоге, никто не обогнал Subversion. Здесь больше функций, чем в любой другой рассмотренной нами системе, выше стабильность и полнее поддержка. Subversion также сравнительно проста для каждого, имеющего опыт работы с CVS, да и вообще удобна – и для маленьких проектов с парой программистов, и для огромных, имеющих тысячи разработчиков. Именно комбинация проверенной и заслуживающей доверия технологии с разносторонностью, достаточной для удовлетворения потребностей большинства людей, позволила Subversion победить. Наличие ряда графических оболочек, как и интеграция во многие популярные IDE, также помогли сделать Subversion хорошим выбором для тех, кто не хотел бы надолго оставаться один на один с командной строкой.

Без сомнения, в целом качество систем управления версиями, рассмотренных в этом Сравнении, невероятно высокое. Даже последние двенадцать месяцев продемонстрировали впечатляющий прогресс. Достаточно взглянуть, каких успехов достиг Git за столь короткое время, чтобы понять, как быстро все это развивается, и насколько жизненно необходимыми являются системы управления версиями для будущего Linux. И если по усердию, с которым разрабатываются системы управления версиями, судить о будущем Linux, то оно выглядит прекрасным.

Врезки

Терминология управления версиями

Несмотря на значительные различия между отдельными системами управления версиями, они используют общие термины:

  • Репозиторий (repository). Здесь размещаются все файлы проекта. Репозиторий может размещаться на удаленном сервере, локально на вашем компьютере, или и там, и там.
  • Рабочая копия (working copy). Ваша личная версия репозитория, включающая все сделанные вами изменения и модификации. Также известна как «песочница» (sandbox).
  • Фиксация (commit). Загрузка в репозиторий изменений, которые вы сделали локально. Если возникнут конфликты, вам нужно будет разобраться с ними.
  • Ветвь (branch) или ответвление (fork). Пометка набора изменений как изолированных от основной ветви разработки. Удобно для работы над новыми версиями и выпусками исправлений.
  • Выписка (checkout). Получение копии проекта из рабочего репозитория. Впоследствии она становится вашей рабочей копией.

Таблица функций

Lxf91 func tabl.PNG

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF91:%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F%D0%BC%D0%B8&oldid=3710»
Персональные инструменты
купить
подписаться
Яндекс.Метрика