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

Системы управления версиями (VCS) или Системы управления исходным кодом (SMS) - важный аспект разработки современного ПО. Его неиспользование сродни вождению машины слишком быстро: это смешно, и вы можете попасть в пункт назначения быстрее, но катастрофа неизбежна. Эта статья дает обзор систем Управления Конфигурации ПО (SCM) и их преимущества, включая CVS, Subversion, Arch и Git. Наконец, она рассматривает некоторые из новых подходов, которые пригодны и как они отличаются от прежних методов. [Листинг 4 был обновлен в соответствии с улучшениями синтаксиса Git

Что такое управление конфигурацией ПО?

SCM - одно из тех важнейших средств, которое вы, возможно, не изучали в школе. Как следует из названия, управление ПО (или исходным кодом) - это средство и соответствующий процесс, используемый для поддержки исходного кода и его изменения с течением времени. SCM предоставляет следующие возможности:

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

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

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

Язык SCM

Прежде чем глубоко нырнуть в детали и типы архитектур для SCM, вам нужно выучить словарь. Первый термин - репозиторий (repository). Репозиторий - это центральное место, где хранятся файлы (иногда его называют деревом [tree]). Извлечение файлов из репозитория в рабочую директорию вашей локальной системы называется выгрузка (check-out). Если вы делаете изменения в файлах локально, для их синхронизации с изменениями файлов в репозитории, вам нужно зафиксировать (commit) изменения. Если ваш измененный файл до этого был изменен кем-то еще, произойдет объединение изменений, то есть два набора изменений будут сведены вместе. Если объединение невозможно из-за конфликтующих изменений в файле, возникнет конфликт (conflict). В такой ситуации, commit отклоняется и разработчику приходится согласовывать изменения вручную. Когда изменения зафиксированы, создается новая версия (revision)файла.

У одного или нескольких разработчиков есть возможность работать вне главного дерева (текущего корня репозитория), а именно, в персональной ветке (branch). Это позволяет разработчикам испытывать какие-то процессы в своих ветках, не влияя на главное дерево. Когда они станут стабильными, их можно соединить с главным деревом.

Для того, чтобы пометить начало отсчета изменений в дереве, можно поставить метку (tag) на наборе файлов, сгруппировав таким образом несколько файлов в пригодный для использования блок (иногда используется в качестве конечной версии файлов для какой-то отдельной сборки).

Архитектуры

SCM системы могут значительно различаться, но есть два главных архитектурных различия, которые стоит изучить:

• Централизованные vs. Рассредоточенные репозитории
• Метод "изменений" vs. Метод "моментального снимка"

Централизованные vs. Рассредоточенные репозитории

Одно из наиболее важных архитектурных различий в современных SCM, которое вы можете увидеть и ощутить в своей работе - это идея централизованных репозиториев против рассредоточенных (или нецентрализованных). Наиболее распространенной архитектурой в наши дни является архитектура с централизованным репозиторием. Данная "звездная" (star) архитектура изображается как центральный репозиторий ресурсов и множество разработчиков работающих с ним (см. рисунок 1). Разработчик выгружает код из центрального репозитория на локальную машину (check out), и после внесения изменений, фиксирует их и загружает обратно в центральный репозиторий (commit), таким образом, и другие разработчики имеют доступ к его изменениям.

Рисунок 1. При централизованной архитектуре все разработчики работают с центральным репозиторием.

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

Рассредоточенная архитектура позволяет разработчикам создавать свои собственные локальные репозитории для своих изменений. Локальный репозиторий разработчика такой же, как и исходный репозиторий ресурсов (который был). Ключевым отличием является то, что рассредоточенный подход позволяет разработчикам работать со своими изолированными репозиториями, а не с локальными машинами. Они могут делать изменения, вносить их в свои локальные репозитории и синхронизировать изменения с другими разработчиками, не трогая главную ветку. Затем разработчики могут сделать набор изменений, доступный своим "вышестоящим" коллегам (см. рисунок 2).

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

Нецентрализованная архитектура интересна тем, что независимые разработчики могут работать асинхронно в одноранговой сети (peer to peer). Когда работа закончена (и достаточно стабильна), они могут сделать набор своих изменений (или исправлений) доступным всем остальным. Такая модель в наши дни широко используется в разработке систем с открытым кодом, включая ядро Linux® kernel.

Модель "моментальных снимков" (snapshot model) против Модели "набора изменений" (changeset model)

Другое интересное архитектурное отличие старых SCM от более современных - способ хранения изменений. Теоретически системы одинаковы и дают один и тот же результат, но различаются тем, как хранятся версии файлов (revision).

В модели "моментальных снимков" хранятся файлы целиком для каждой версии (с оптимизацией размера дерева). В модели "набора изменений", хранится только разница в версиях, создавая компактный репозиторий. (Рисунок 3).

Рисунок 3. Каждая из моделей ("снимков" и "наборов изменений") имеет свои преимущества.

Как вы видите из рисунка 3, модели отличаются, но в конечном итоге мы получаем одинаковый результат. В модели "моментальных снимков", вы можете получить версии быстро, но вам потребуется больше места, чтобы хранить их. Модель "набор изменений" потребует меньше места, но займет больше времени, для получения определенной версии, потому что ошибка должна быть учтена в основной версии. Как вы потом увидите, вы можете делать оптимизацию, чтобы минимизировать число ошибок, которые учитываются в модели.

Примеры SCM

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

CVS

Concurrent Versions System (CVS) - одна из наиболее распространенных сегодня SCM. Она имеет централизованную архитектуру с моделью "набора изменений", в которой разработчики работают с центральным репозиторием при совместной разработке программного обеспечения. CVS используется повсеместно и она доступна как стандартная часть любого дистрибутива Linux. Благодаря своему простому и удобному (для многих из нас) синтаксису, она является популярным выбором как при одиночной, так и командной разработке.

Листинг 1 демонстрирует набор простых CVS команд с кратким описанием каждой. Для более подробной информации, обратитесь к секции Ресурсы .

Листинг 1. Примеры команд для CVS

# Создать новый репозиторий cvs -d /home/user/new_repository init # Подсоединиться к корневому репозиторию export CVSROOT=:pserver:user@example.com:/cvs_root # Выгрузить блок для модуля из корневого репозитория cvs checkout project # Обновить локальный блок из корневого репозитория cvs update # Внести изменения из локального блока в коневой репозиторий cvs commit # Добавить новые файлы в локальный блок cvs add # Показать изменения, сделанные в локальном блоке cvs diff

Для любителей интерфейса с использованием координатного указателя ("мышиный" интерфейс) в CVS есть большое количество графических интерфейсов с открытым кодом, которые вы можете использовать, например, WinCVS и TortoiseCVS (которая интегрируется с Microsoft Windows Explorer, если вам это удобно).

Несмотря на повсеместное использование, CVS имеет свои недостатки. CVS не позволяет переименовывать файлы, также она имеет недостатки при работе с определенными файлами, например, с символьными ссылками. Изменения, отслеживаемые самим файлом, могут иногда надоедать. Синхронизация может быть иногда проблематична (CVS внутри использует diff3 для этой цели).

Однако, CVS полезен, если действительно это необходимо сделать, и он пригоден для всех главных платформ. Если вам нравится CVS, в целом, то Subversion может быть для вас как раз тем, что вы ищете.

Subversion

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

Subversion также позволяет удаленный доступ посредством большого количества протоколов, таких как протокол HTTP, протокол безопасности HTTP, или протокол, выполненный по заказу SVN, который также поддерживает туннелирование через Оболочку Безопасности [SSH].

Листинг 2 показывает некоторые из команд, поддерживаемые в Subversion. Мы также включили некоторые из расширений, которые не пригодны для CVS. Посмотрите раздел Ресурсы для более детальной информации о Subversion. Как вы видите, набор команд Subversion действительно похож на набор команд CVS, обеспечивая хорошую альтернативу для CVS-пользователей.

Листинг 2. Примеры команд для Subversion

# Создать новый репозиторий svnadmin create /home/user/new_repository # Выгрузить блок из корневого репозитория svn checkout file:///server/svn/existing_repository new_repository # Обновить локальный блок из корневого репозитория. svn update # Внести изменения из локального блока в корневой репозиторий. svn commit # Добавить новые файлы в локальный блок svn add # Показать изменения, сделанные в локальном блоке svn diff #Переименовать файл в локальном блоке svn rename # Удалить файлы svn delete

Следуя традициям CVS, Subversion использует в работе графический внешний интерфейс, такой как ViewCVS and TortoiseSVN. Существуют также средства конвертировать репозиторий CVS в Subversion (такие как cvs2svn.py), но они, как сообщают, управляются не со всем набором ответвлений и сопровождений данных тегами в случаях сложных репозиториев. Учитывая все Open Source проекты, со временем ситуация улучшится. Subversion также использует в работе TortoiseMerge в качестве различия между средствами отображения и исправления.

В Subversion фиксированое число выпусков, испытанных CVS пользователями, такие как организация разработки новых поколений определенных файлов, мелких действий и отладок. Если вам нравится CVS и вам нравится подход центрального репозитория, то Subversion - это SCM для вас.

Теперь давайте оттолкнемся от централизованного подхода и рассмотрим пример, когда некоторые думают, что реальное будущее SCM - это объединение децентрализованных репозиториев.

Arch

Arch - это подробное детализированное описание для децентрализированной SCM, которое предлагает множество различных моделей. Они включают в себя ArX, Bazaar, GNU Arch, и Larch. Arch не только оперирует как децентрализованная SCM (как показано на рисунке 2), но также использует модель "набора изменений" (рисунок 3). Arch SCM - популярный метод для разрабоки Open Source, поскольку разработчики смогут создавать в отдельных репозиториях с полным контролем исходного кода. Это происходит потому что рассредоточенные репозитории - действующие репозитории, дополненные контролем проверок (revision). Вы можете создавать patch из изменений в локальной репозитории, используемом вышестоящим разработчиком. Это большое преимущество децентрализованной модели.

Как и Subversion, Arch корректирует число выпусков в CVS. Они включают в себя изменения метаданных, такие как пересматривание разрешений файла, обработка удаления и переименования файлов, и небольшие сравнения (слияние сравнений вместо отдельно действующих сравнений).

Листинг 3 показывает некоторые из команд, которые вы найдете в Arch SCM. Мы продемонстрировали здесь GNU arch, так как он разработан архитектором Arch, Томом Лордом. GNU arch обеспечивает базу, которую вы ждете от SCM, включая новейшие опции, имеющиеся в Subversion.

Листинг 3. Примеры команд для GNU arch (tla)

# Регистрация публичного архива tla register-archive http://www.mtjones.com/arch # Выгрузка локального репозитория из вышестоящего. tla get project@mtjones.com--dev/project--stable myproject # Обновление из локального репозитория. tla update # Внесение изменений в локальный репозиторий. tla commit # Добавление новых файлов в локальный репозиторий. tla add # Показать изменения, сделанные в локальном репозитории. tla what-changed # Переименовать файл в локальном репозитории. tla mv # Удалить фaйлы (также удалить из репозитория) tla rm

Arch также позволяет синхронизировать изменения от вышестоящих репозиториев. Чтобы минимизировать число исправлений, которые нужно будет применить к основной проверке (посредством модуля "набора изменений"), команда "cacherev" создаст новый "моментальный снимок" основной проверки в репозитории.

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

Наибольший протест от новых пользователей tla вызвала некоторая запутанность Arch. Другие действия Arch, такие как baz, как говорят эксперты, полегче. Вы можете рассматривать их, если tla не удовлетворит ваши требования.

Теперь рассмотрим окончательную децентрализованную SCM, написанную разработчиком ядра Linux собственноручно, Линусом Торвальдом.

Git

Git SCM был разработан Линусом Торвальдом как прямая замена для Bitkeeper SCM (см. секцию Ресурсы Это очень просто, но это стоит работы децентрализованной SCM, основанной на методе "набора изменений" и используется как SCM для ядра Linux. Он использует модель группировки файлов больше, чем отслеживание отдельными файлами. Изменения сжаты и раздроблены с помощью SHA1, подтверждая их целостность. (см. листинг 4)

Листинг 4. Примеры команд для Git

# Получить Git репозиторий (впервые) git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git # Обновить Git репозиторий из определенного вышестоящего Git репозитория git pull # Выгрузить из Git репозитория в локально работающий репозиторий. git checkout # Добавить изменения в локальный Git репозиторий git commit # Внести изменения в вышестоящий (потребует SSH доступ к вышестоящему git push # Добавить новые файлы в локальный репозиторийires (commit) git add # Показать изменения, сделанные в локально работающей дирктории git diff # Удалить файлы git rm

Git SCM - самодостаточен в своем собственном репозитории Git, что обозначает что вы должны загрузить Git, чтобы инсталлировать его на своей машине. Набор команд для Git, схожий с тем, что вы видели до этого, - относительно основной набор команд.

Вы можете спросить, почему не рассматриваем ни одну из существующих SCM, кроме тех, которые описаны здесь? Это хороший вопрос. Git интересен и сохраняет большую пользовательскую базу разработчиков ядра Linux, поэтому это могло быть следующей большой SCM. Линус описывает Git как очень быстрого менеджера содержимого директории, который хоть и не делает много, но делает это эффективно.

Преимущества

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

Используете ли вы централизованный или рассредоточенный репозиторий, модель "снимка" или "изменений", преимущества одинаковы. Так как разработка современного ПО не обходится без SCM, используйте SCM заблаговременно и используйте его часто!

Взгляд в будущее

Эта статья - поверхностный взгляд на SCM в его использовании на сегодняшний момент. Существует много других Open Source SCM, включая Aegis, Bazaar-NG, DARCS, и Monotone, к примеру. Как редакторы и языки, SCM могут быть неясными, поскольку они редко используются в изоляции, и, таким образом, обычно выбираются командами больше, чем в индивидуальном порядке (если у вас не особо властный начальник, который любит принимать решения за вас). Поэтому, играйте с возможностями и развивайтесь в разных направлениях. SCM - необходимый инструмент в разработке ПО и значительная часть вашего технической панели инструментов.