III Международная студенческая научная конференция Студенческий научный форум - 2011

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

Большинство систем управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, т. н. «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время. Сервер может использовать т. н. дельта-компрессию - такой способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.

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

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

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

Многие системы управления версиями предоставляют ряд других возможностей:

• Позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными - после неё.
• Дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле.
• Ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии.
• Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.

Централизованные СУВы

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

Первым делом в репозиторий добавляется новый проект. Это могут быть файлы пустого проекта, созданные в одной из сред разработки, куда в дальнейшем будут вноситься изменения. Контролю версия обычно подлежат только текстовые файлы с кодом, но некоторые СУВ позволяют так же работать с бинарными файлами. Для исполняемого кода в этом нет необходимости, так как он всегда одинаково генерируется компилятором, а, например, учитывать изменение картинок для WEB-проекта является весомым

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

Рабочая копия (working copy) - это копия проекта, которую участники проекта будут использовать в своей ежедневной разработке. Как только участник проекта получает локальную копию, с ней можно работать обычным образом. Так же есть возможность добавлять и удалять файлы из репозитория, что бывает необходимо при расширении или изменении структуры проекта.

После совершения ряда изменений можно сохранить их на сервер (команда commit или check in). Тут, начинается политика конкретной команды разработчиков, касающаяся правил внесения изменений в репозиторий. Нормой считается внесение только проверенных изменений, для которых был проведен ряд рабочих тестов. Обычно централизованные СУВ позволяют осуществлять две политики работы с изменениями. В первом случае над одним файлом может работать только один пользователь. Т.е. если кто-то один взял себе рабочую копию, для других она становится недоступной. Во втором случае над одними и теми же файлами могут работать разные люди. В таких случаях, при попытки сохранить изменения на сервер будет производиться попытка слияния (merge) файлов которые изменялись более чем одним пользователем. Существуют методы автоматического слияния кода, но при возникновении конфликтов, когда один и тот же отрывок текста был изменен в обоих случаях, предлагается возможность их разрешить, т.е. выбрать окончательный вариант изменений, устраивающий обоих пользователей. Для этого существуют средства автоматизации.

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

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

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

Обзор централизованных СУВ

CVS

CVS - система контроля версий с открытым кодом, появившаяся в 1980-ых и до сих пор используемая многими организациями.

Она использует клиент-серверную архитектуру, сохраняя файлы на сервере в виде RCS-файлов (а RCS - это «еще более древняя, чем CVS» система контроля версий, на базе которой построена CVS).

Обзор CVS был бы неполным без указания ряда минусов при его использовании. Короткий список того, что признают многие разработчики:

• Медленные операции пометки и ветвления;
• Невозможны переименовывание файлов и перемещение каталогов;
• Коммиты не атомарны;
• Плохая поддержка бинарных файлов.

Да, в отличие от большинства современных систем управления версиями, коммиты в CVS не атомарны.

В системе управления версиями, которые поддерживают атомарность коммитов, измененные файлы публикуются в репозитории не «по очереди», а группой (обычно именуемой как change set, «набор изменений»).

При этом, если корректное слияние с существующими в репозитории исходниками невозможно, или если передача изменений «обрывается» (например, из-за сбоев сети), то коммит прерывается и репозиторий останется неизменным. Это гарантирует, что исходный код в репозитории всегда остается согласованным и целостным.

А когда вы фиксируете изменения CVS-ом, не гарантируется, что все они будут полностью и корректно внесены в репозиторий. Если по какой-либо причине коммит не удался, исходный код в репозитории может быть в «нестабильном» состоянии. Это основной архитектурный недочет в CVS.

Многие разработчики также испытывают трудности при использовании CVS-тэгов и веток при разработке широкомасштабного проекта.

Обновление всех файлов «по одному» может быть долгим процессом. К примеру, если вам нужно пометить ваш проект, который содержит 1000 файлов, CVS будет метить каждый файл в вашем проекте поочередно, то есть для каждого файла будет отдельное сетевое взаимодействие. Для большого проекта этот процесс может занять часы.

•                        Subversion

Subversion - это относительно новый продукт, специально разработанный, чтобы исправить известные недостатки CVS.

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

Другая приятная особенность Subversion заключается в легкости настройки сервера Apache для предоставления доступа через HTTP (или HTTPS) к вашему репозиторию, так что вы можете просматривать ваш репозиторий, используя обычный веб-браузер.

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

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

CVS - это файло-ориентировнная система, которая ведет отдельную историю версий для каждого файла. Subversion же отслеживает целые ревизии.

Ревизию можно рассматривать как снимок каталога проекта со всем его содержимым в определенный момент времени.

Ревизии - это краеугольный камень атомарных обновлений в Subversion.

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

Альтернативный взгляд на этот подход - это то, что любой набор изменений может быть представлен как «отдельная связка», относящаяся к определенному разработчику.

Это также делает более эффективной обработку бинарных файлов и ускоряет создание меток и ветвей.

Распределенные СУВы

Распределенные системы контроля версий сильно отличаются от централизованных по своему дизайну и философии. Они основаны на философии распределенных хранилищ без выделенного центрального сервера.

Отсутствие центрального сервера - это и главное достоинство, и основная слабость распределённой системы контроля версий.

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

Если разработчик работает над несколькими ветками, у него будет несколько полных копий репозитория.

Это устраняет зависимость от центрального сервера, и потенциально делает систему более устойчивой.

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

Для крупных проектов через некоторое время распределённая модель может привести к видимым проблемам с объемом используемого дискового пространства и падением производительности.

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

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

Рассмотрим как это работает.

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

Отметим, что команда commit (или check in) обновляет только локальную копию репозитория. Поскольку не существует центрального сервера для обновлений, только у вас будет новейший репозиторий. В этом состоит главная разница между распределённой системой управления версиями и централизованной, такой, как CVS или Subversion.

Чтобы обновить другой репозиторий, вы должны распространить ваши изменения на этот репозиторий, используя команду push. Либо другой разработчик может извлечь ваши изменения для своей локальной копии репозитория, используя команду pull.

По аналогии с централизованными СУВ в распределенных вы как бы создаете каждый раз свою отдельную ветвь проекта, с которой работаете только вы, а потом сливаете ее с основным стволом проекта.

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

Обзор существующий СУВ

Mercurial

Mercurial - кроссплатформенная распределённая система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода. Mercurial первоначально был написан для Linux, позже портирован под Windows, Mac OS X и большинство Unix-систем. В первую очередь он является консольной программой. Все его операции запускаются параметрами программы hg, название которой взято от обозначения химического знака ртути (ртуть по англ. - mercury).

Система Mercurial написана на Python, хотя чувствительные к производительности части (например, своя реализация diff) выполнены в качестве Python-расширений на C. Репозитории Mercurial управляются при помощи утилиты командной строки hg.

Наряду с традиционными возможностями систем контроля версий, Mercurial поддерживает полностью децентрализованную работу (отсутствует понятие основного хранилища кода), ветвление (возможно вести несколько веток одного проекта и копировать изменения между ветками), слияние репозиториев (чем и достигается «распределённость» работы). Поддерживается обмен данными между репозиториями через HTTP/HTTPS, SSH и вручную при помощи упакованных наборов изменений.

Mercurial использует SHA1-хеши для идентификации ревизий и позволяет присваивать отдельным ревизиям индивидуальные метки.

Утилита hg обладает компактным интерфейсом, и Mercurial считается более простой в освоении системой, чем, например, git.

Bazaar

Bazaar  (ранее известная как Bazaar-NG, имя утилиты командной строки bzr) - распределённая система управления версиями, разработка которой спонсируется фирмой Canonical Ltd.. Система Bazaar  разработана с целью облегчить работу над развитием свободных и открытых проектов для всех желающих.

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

Система контроля версий Bazaar написана на языке программирования Python. Существуют установочные пакеты для основных дистрибутивов GNU/Linux, инсталляторы для Mac OS X и MS Windows. Bazaar - это свободное программное обеспечение, в настоящее время является частью проекта GNU.

оманды Bazaar очень похожи на команды, используемые в CVS или SVN. Для создания и поддержки нового проекта без использования специального сервера с репозиторием пользователю достаточно запустить команду bzr init в том каталоге, который нужно поместить под контроль версий.

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

Bazaar поддерживает работу напрямую с некоторыми другими системами контроля версий. Пользователи могут создавать новые ветки на основе репозиториев других систем (таких как Subversion или Git), делать локальные изменения и фиксировать их в Bazaar-ветке, и затем отправлять свои изменения назад в оригинальный репозиторий. Bazaar поддерживает базовые операции с Subversion (требуется плагин bzr-svn), а также с Git (требуется плагин bzr-git) Также начата работа над поддержкой Mercurial. Плагин bzr-hg умеет пока немногое, однако его функций достаточно, чтобы отобразить историю ревизий в графическом виде.

Bazaar поддерживает полный набор символов Unicode в именах файлов. Система также позволяет использовать Unicode для составления комментариев к ревизиям, в именах авторов изменений и т.д.

Git

Git (произн. «гит») - распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано (англ. Junio C. Hamano).

Примерами проектов, использующих Git, являются Linux kernel, Cairo, GNU Core Utilities, Mesa, Wine, Chromium и некоторые дистрибутивы GNU/Linux (см. ниже).

Программа является свободной и выпущена под лицензией GNU GPL версии 2.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использование существующих конфигураций сетевых фильтров.

Вывод

Системы управления версиями - необходимый инструмент для разработчиков программных продуктов, особенно для коллективных проектов.

Код для цитирования: Скопировать