Bozaro

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

Типичные задачи, которые позволяет решить система контроля версий:

1. Узнать, что я поменял с момента последней «живой» копии?
2. Получить исходник установленной месяц назад системы.
3. Параллельная работа 2-х и более человек над одним исходником.

В практической работе мне довелось использовать 4-ре системы контроля версий:

1. CVS
2. Microsoft SourceSafe
3. Subversion
4. GIT

Краткое описание каждой из них.

CVS

Первая система контроля версий с которой мне пришлось работать. На данный момент CVS является устаревшей. С CVS проще всего перейти на Subversion.

Минусы CVS по сравнению с Subversion:

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

Microsoft Visual SourceSafe (VSS)

Если у кого-нибудь есть мысль использовать для работы SourceSafe – хорошо подумайте еще раз.

Я пользовался SourceSafe около полугода и с меня этого хватило: никогда не используйте Microsoft SourceSafe. Чтобы не быть голословным, перечислю её плюсы и минусы.

Плюсы Microsoft SourceSafe:

1. Интеграция с Visual Studio.

Минусы Microsoft SourceSafe:

1. SourceSafe требует Checkout-а файла перед его изменением.
   Это имеет следующие подводные камни:
   • невозможно работать из другой ОС, например Linux, так как придется постоянно перезагружаться;
   • при Checkout-е забирается последняя версия файла (вроде бы исправлено в VSS 2005);
     Например: есть если ты меняешь файлы и тебе понадобилось изменить еще один файл, то в случае если его кто-то другой успел поменять, тебе придется сводить изменения при еще незаконченной правке кода. Удовольствие ниже среднего.
2. SourceSafe не отслеживает удаления файлов.
   То есть если кто-то удалил файл из репозитория, то у всех остальных он локально останется (особенно интересно это выглядит после перемещения .h-файлов). То есть в случае активной работы исходный код начинает расходиться. И возникает ситуация, когда у двух разработчиков последняя версия и в Checkout-е ничего нет, но у одного все работает, а у другого – нет.
3. SourceSafe при откатывании изменении удаляет историю правок.
   То есть, если кто-то откатился до 1-ой версии – пиши пропало;
4. Размер базы исходного кода ограничен 4Гб;
5. На сколько мне известно, VSS единственная система контроля версий, разработчики которой не пользуются ей для хранения исходного кода (исходный код у Subversion лежи в Subversion, у GIT-а в GIT и т.д.).

Subversion

Subversion специально разрабатывался для замены CVS и является своеобразной работой над ошибками. По этой причине синтаксис многих команд у CVS и Subversion почти совпадает.

В качестве основных плюсов Subversion по сравнению с CVS  можно перечислить:

1. Не нужно явно указывать бинарный файл, или текстовый;
2. Появились атрибуты файлов и каталогов (через них, например можно сделать файл исполняемым для Linux из Windows);
3. Отслеживается работа с директориями и перемещением файлов;
4. Атомарные коммиты;
5. Версии всех файлов имеют единую сквозную нумерацию – ревизию.

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

GIT

GIT был разработан Линусом для работы над ядром Linux-а.

В отличие от Subversion, GIT является децентрализованной системой контроля версий. Каждый работает со своим репозиторием, изменения из которого периодически переносятся в основной.

То есть в GIT есть локальные коммиты/обновления для рабочей копии и есть коммиты/обновления для репозитория в целом.

Так же GIT позволяет передать сделанные изменения по почте. Это позволяет штатными средствами GIT получать патчи от людей, которые не имеют доступа к центральному репозиторию.

Субъективное сравнение Subversion и GIT

При выборе между Subversion и GIT надо понимать, что основное отличие у них в стиле работы. По этой причине надо исходить из поставленной задачи.

Наиболее существенные отличия в пользу Subversion:

1. Subversion – централизованная система контроля версий, что позволяет иметь сравнительно небольшую рабочую копию;
2. Subversion хорошо работает под Windows, не имеет проблем с кириллицей, в Windows есть очень удобный интерфейс TortoiseSVN (у GIT проблемы с кириллицей под Windows в силу его молодости);
3. Subversion позволяет держать в рабочей копии часть репозитория;
4. Subversion имеет очень приятную вешь: svn:externals. Она позволяет разделить проекты с общими модулями, но об этом чуть ниже;
5. Subversion имеет сквозную нумерацию ревизий.

Наиболее существенные отличия в пользу GIT:

1. GIT – распределенная система контроля версий. В случае сбоя можно взять локальный репозиторий без потери истории изменений;
2. GIT быстрее, чем Subversion. При тестовом сравнении скорости я получил разницу более чем в 10 раз;
3. GIT позволяет получать патчи от сторонних независимых разработчиков по e-mail;
4. GIT позволяет делать локальные коммиты без доступа к центральному серверу.

Пример структуры репозитория в Subversion

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

Для решения проблемы использования общих модулей пришел к следующей схеме репозитория:

• tags – метки
• branch – ветви
• trunk – рабочая ветвь
  • modules – модули
    • module1
    • module2
    • module3
  • projects – проекты
    • project1 (svn:externals = «../../modules/module1 module1\n../../modules/module2 module2″)
    • project2 (svn:externals = «../../modules/module1 module1\n../../modules/module3 module3″)

То есть все необходимые для работы модули подключаются в проект через svn:externals. Для работы над проектом достаточно зачекаутить только его.

К сожалению при коммите Subversion иногда отказывается коммитить одновременно несколько, подключенных через svn:externals, модулей. Так же «svn update -r 2034″ в корне проекта обновит все модули до ревизии HEAD, а не 2034.

В качестве обходного варианта, для получении старого исходника конкретной версии, указанная версия копируется в tags/branch, например: svn copy trunk@2034 tags/rev-2034