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

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

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

В любом приложении реализован как минимум базовый уровень локального управления версиями, состоящий из функций «отменить» и «повторить ». Некоторые программы, такие как Microsoft Office и документы Google , содержат более сложные функции, такие как сравнение версий и комментирование.

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

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

Распределенное управление версиями

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

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

Централизованное управление версиями

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

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

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

Заключение

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

Перевод статьи «What is version control » дружной командой проекта .

Хорошо Плохо

Миша Радионов

Что такое системы контроля версий и зачем они нужны Вам

Вернуться в

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

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

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

Что такое VCS?

Система управления версиями (от англ. Version Control System, VCS или Revision Control System) - программное обеспечение для облегчения работы с изменяющейся информацией.Wikipedia

А теперь по-простому

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

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

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

Простой пример

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

Система контроля версий в студии Флаг

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

Мы используем программу для разработки программного кода, которая называется IntelliJ IDEA . Она предоставляет собой IDE, то есть большую функциональную базу для разработчиков, в том числе в нее включен удобный интерфейс по работе с контролем версий. Так, не выходя из программы, мы можем увидеть, какие изменения были произведены тем или иным разработчиком на нужном нам сайте. Или, не боясь потерять свои изменения, получить изменения, сделанные другим разработчиком. Выглядит интерфейс IDEA примерно так:

Для хранения версий мы пользуемся облачным сервисом Bitbucket . Этот сервис удобен своим интерфейсом и, помимо услуг по хранению ваших версий, позволяет управлять правилами доступа к вашим продуктам разным пользователям. Плюсом использования облачного хранилища является отсутствие каких-то требований к знанию настройки и администрирования сервера. Вы все получаете “из коробки” и сразу можете начинать пользоваться. Все, что вы загружаете в bitbucket, является приватным, т.е. без вашего разрешения никто другой не сможет даже увидеть, что вы храните. Интерфейс Bitbucket:

Что нам дает использование VCS

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

Что это дает нашим клиентам

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

Please enable JavaScript to view the

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

Что это такое?

Итак, системы управления версиями (СУВ) - это такая программка, которая позволяет сохранять всю историю разработки проекта.

Зачем это нужно?

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

К примеру, недавно у меня начали падать ограничения по скорости в проекте на FPGA. Я буквально за 5 минут нашел версию, в которой они еще не падали и нашел в чем причина

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

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

Какую выбрать?

Систем контроля версий существует огромное множество. Лично я для себя выбрал Mercurial . Отличная система, которую всем рекомендую - быстрая, кросплатформеная, с отличным графическим клиентом. Очень весомым аргументом в ее пользу оказалось существование сайта . Я ни разу не пожалел о выборе.

Кроме Mercurial, сейчас довольно распространены git и svn . Git больше распространен в около linux"овской тусовке, svn - в корпоративной среде. Я их попробовал использовать (правда, очень не долго), но ничего такого, из-за чего стоило бы бросать mercurial я не увидел.

Есть такой сайт , на нем можно хранить ваши проекты. Он примечателен тем, что там, в отличии от github можно бесплатно создавать закрытые репозитории (репозиторий - место, где хранится проекты). Платить нужно только за те проекты, которые закрыты и над которыми работает больше, чем 5 человек. При этом, лимит можно расширить до 8ми, рассылая приглашения. Я, пока, не превышал этого лимита. Кроме этого, есть wiki и багтрекер, вообщем, все, что нужно для разработки проектов.

Когда я начинал с ним работать, сайт поддерживал только Mercurial (отчасти из-за этого, я и выбрал mercurial), но сейчас там можно создавать и git-репозитории. Кроме того, к bitbucket можно привязать свой домен. Вот, к примеру, мой вариант: hg.bsvi.ru

Как начать?

Сначала нужно скачать клиент. Я использую tortoiseHg . Думаю, с установкой проблем не возникнет.

После установки, неплохо бы задать имя пользователя по умолчанию. Для этого, нужно отредактировать файл С:/Users/BSVi/mercurial.ini туда нужно добавить строчку

Username = bsvi

Естественно, bsvi нужно заменить на ваше имя.

Теперь мы готовы создать проект и начать что-то делать. Для этого на жмем «Create repository»:

Там заполняем название, описание, выбираем язык. Можно добавить wiki и багтрекер.

Теперь жмем на кнопку «clone» и копируем то, что там появилось:

Дальнейшие операции зависят от того, какой файловый менеджер вы используете. Лично я использую far. Я просто вставляю скопированную строчку в коммандную строку:

Если вы испольуете проводник (эм), total commander или что-то в таком духе, то нужно щелкнуть правой кнопкой мышки и выбрать:


Там, в поле source нужно вставлять путь, естественно, без hg clone:

Вас спросят о вашем пароле, и появится директория test-repo, в которой, собственно и будет находиться проект.

Добавим немного файлов

Если у вас уже есть наработки по проекту, их можно просто скопировать в директорию. Мы-же, для учебных целей, создадим файл main.c с вот таким содержимым:

#include int main() { return 0; }

Теперь сделаем коммит. Коммит - это внесение изменений в проект. Для этого запускаем hg workbench. Я просто пишу в командной строке thg, для эксплорерообразных файловых менеджеров нужно нажать ПКМ->Hg Workbench.

Напротив нашего файла будет знак вопроса (это значит, он не добавлен в проект). Поставим около него галочку и напишем описание того, что было сделано:


Естественно, после этого, жмем кнопку «commit».

Все, изменения в проект внесены. Тут нужно обратить внимание, что изменения внечены только на локальном компьютере (тоесть, их еще нету на сервере). Для того, чтобы перенести изменения на сервер, нужно нажать кнопку «push», вот она:

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

Изменим файл

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

#include int main() { printf("mercurial rules!"); return 0; }

Перейдем в hg workbench. Я когда работаю над проектом его даже не закрываю (об этом-дальше), нажимаем f5 чтобы обновить список файлов. Теперь видно, что изменилось со времени последнего коммита:

И это - очень сильный инструмент. Обычно, во время отладки в файлах появляется куча разного мусора. Дак вот, просматривая то, что вы собираетесь закоммитить очень неплохо очищает от мусора проект.

А что делать с мусором?

При работе над проектом появляется очень много мусора - к примеру, объектные файлы, файлы, которые генерирует IDE, какие-то временные файлы, итп. Все, то, что не относится к самому проекту, неплохо бы убрать из репозитория. Для этого существует файл.hgignore (да, с точкой в начале названия).

Добавим мусорный файл к проекту. Я, к примеру, создал main.obj:

Если сейчас обновить список файлов, то, естественно, hg workbench предложит добавить этот файл в проект:

Теперь, создадим файл.hgigonre и напишем там, что мы хотим игнорировать все файлы с расширением obj:
syntax:glob *.obj

Если обновить список файлов, то obj файлы пропадут, зато появится файл.hgignore, который можно закоммитить:

А как откатить изменения?

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

Точно практически так-же можно откатить отдельный файл.

Заключение

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

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

Для примера, вот скриншот моего UTC (который я разрабатываю сам) в самом сложном месте в hg workbench:

Обзор систем контроля версий

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

Для сравнения были выбраны наиболее распространенные системы контроля версий: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce, Mercurial, TFS.

RCS - система управления пересмотрами версий.
(www.gnu.org/software/rcs/rcs.html)

Начнем наш обзор с одной из первых систем контроля версий – RCS (Revision Control System – система управления пересмотрами версий), разработанной в 1985 году. Она пришла на смену популярной в то время системы контроля версий SCCS (Source Code Control System – система управления исходным кодом).

На данный момент RCS активно вытесняется более мощной системой контроля версий CVS, но все еще - достаточно популярна, и является частью проекта GNU.

RCS позволяет работать только с отдельными файлами, создавая для каждого историю изменений. Для текстовых файлов сохраняются не все версии файла, а только последняя версия и все изменение, внесенные в нее. RCS также может отслеживать изменения в бинарных файлах, но при этом каждое изменение хранится в виде отдельной версии файла.

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

Рассмотрим основные преимущества и недостатки системы контроля версий RCS.

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

1. RCS - проста в использовании и хорошо подходит для ознакомления с принципами работы систем контроля версий.

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

3. Широко распространена и предустановленна в большинстве свободно распространяемых операционных системах.

Недостатки:

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

2. Не позволяет одновременно вносить изменения в один и тот же файл несколькими пользователями.

3. Низкая функциональность, по сравнению с современными системами контроля версий.

Выводы:

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

CVS - система управления параллельными версиями.
(www.nongnu.org/cvs)

Система управления параллельными версиями (Concurrent Versions System) – логическое развитие системы управления пересмотрами версий (RCS), использующая ее стандарты и алгоритмы по управлению версиями, но значительно более функциональная, и позволяющая работать не только с отдельными файлами, но и с целыми проектами.

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

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

Приведем основные достоинства и недостатки системы управления параллельными версиями.

Достоинства:

1. Несколько клиентов могут одновременно работать над одним и тем же проектом.

2. Позволяет управлять не одним файлом, а целыми проектами.

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

4. Широко распространена и поставляется по умолчанию с большинством операционных систем Linux.

5. При загрузке тестовых файлов из репозитория передаются только изменения, а не весь файл целиком.

Недостатки:

1. При перемещении или переименовании файла или директории теряются все, привязанные к этому файлу или директории, изменения.

2. Сложности при ведении нескольких параллельных веток одного и того же проекта.

3. Ограниченная поддержка шрифтов.

4. Для каждого изменения бинарного файла сохраняется вся версия файла, а не только внесенное изменение.

5. С клиента на сервер измененный файл всегда передается полностью.

6. Ресурсоемкие операции, так как требуют частого обращения к репозиторию, и сохраняемые копии имеют некоторую избыточность.

Выводы:

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

Система управления версиями Subversion.
(www.subversion.tigris.org)

Subversion – эта централизованная система управления версиями, созданная в 2000 году и основанная на технологии клиент-сервер. Она обладает всеми достоинствами CVS и решает основные ее проблемы (переименование и перемещение файлов и каталогов, работа с двоичными файлами и т.д.). Часто ее называют по имени клиентской части – SVN.

Принцип работы с Subversion очень походит на работу с CVS. Клиенты копируют изменения из репозитория и объединяют их с локальным проектом пользователя. Если возникают конфликты локальных изменений и изменений, сохраненных в репозитории, то такие ситуации разрешаются вручную. Затем в локальный проект вносятся изменения, и полученный результат сохраняется в репозитории.

При работе с файлами, не позволяющими объединять изменения, может использоваться следующий принцип:

1. Файл скачивается из репозитория и блокируется (запрещается его скачивание из репозитория).

2. Вносятся необходимые изменения.

3. Загружается файл в репозиторий и разблокируется (разрешается его скачивание из репозитория другим клиентам).

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

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

Достоинства:

1. Система команд, схожая с CVS.

2. Поддерживается большинство возможностей CVS.

3. Разнообразные графические интерфейсы и удобная работа из консоли.

4. Отслеживается история изменения файлов и каталогов даже после их переименования и перемещения.

5. Высокая эффективность работы, как с текстовыми, так и с бинарными файлами.

6. Встроенная поддержка во многие интегрированные средства разработки, такие как KDevelop, Zend Studio и многие другие.

7. Возможность создания зеркальных копий репозитория.

8. Два типа репозитория – база данных или набор обычных файлов.

9. Возможность доступа к репозиторию через Apache с использованием протокола WebDAV.

10. Наличие удобного механизма создания меток и ветвей проектов.

11. Можно с каждым файлом и директорией связать определенный набор свойств, облегчающий взаимодействие с системой контроля версии.

12. Широкое распространение позволяет быстро решить большинство возникающих проблем, обратившись к данным, накопленным Интернет-сообществом.

Недостатки:

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

2. Существуют проблемы с переименованием файлов, если переименованный локально файл одним клиентом был в это же время изменен другим клиентом и загружен в репозиторий.

3. Слабо поддерживаются операции слияния веток проекта.

4. Сложности с полным удалением информации о файлах попавших в репозиторий, так как в нем всегда остается информация о предыдущих изменениях файла, и непредусмотрено никаких штатных средств для полного удаления данных о файле из репозитория.

Выводы:

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

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

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

Aegis, созданная Питером Миллером в 1991 году, является первой альтернативой централизованным системам управления версиями. Все операции в ней производятся через файловую систему Unix. К сожалению, в Aegis нет встроенной поддержки работы по сети, но взаимодействия можно осуществлять, используюя такие протоколы, как NFS, HTTP, FTP.

Основная особенность Aegis – это способ контроля вносимых в репозиторий изменений.

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

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

В третьих, предусмотрена иерархия доступа к репозиторию, основанная на системе прав доступа Unix-подобных операционных систем к файлам.

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

Выделим основные достоинства и недостатки системы контроля версий Aegis.

Достоинства:

1. Надежный контроль корректности загружаемых изменений.

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

3. Качественная документация.

4. Возможность переименовывать файлы, сохраненные в репозитории, без потери истории изменений.

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

Недостатки:

1. Отсутствие встроенной поддержки сетевого взаимодействия.

2. Сложность настройки и работы с репозиторием.

3. Слабые графические интерфейсы.

Выводы:

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

Система управления версиями Monotone.
(monotone.ca)

Monotone – еще одна децентрализованная система управления версиями, разработанная Грейдоном Хоэм. В ней каждый клиент сам отвечает за синхронизацию версий разрабатываемого продукта с другими клиентами.

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

Работа с Monotone строится следующим образом. В первую очередь, создается база данных проекта SQLite, и генерируются ключи с использованием алгоритма хеширования SHA1 (Secure Hash Algorithm 1).

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

Для синхронизации проекта с другими пользователями необходимо:

Экспортировать ключ (хэш - код последней версии проекта) и получить аналогичные ключи от других клиентов.

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

Обобщим достоинства и недостатки системы контроля версий Monotone.

Достоинства:

1. Простой и понятный набор команд, схожий с командами Subversion и CVS.

2. Поддерживает переименование и перемещение файлов и директорий.

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

Недостатки:

1. Низкая скорость работы.

2. Отсутствие мощных графических оболочек.

3. Возможные (но чрезвычайно низкие) совпадения хэш - кода отличных по содержанию ревизий.

Выводы:

Monotone - это мощный и удобный инструмент для управления версиями разрабатываемого проекта. Набор команд - продуман и интуитивно понятен, особенно, он будет удобен для пользователей, привыкших к работе c Subversion и CVS. Прекрасно оформленная и полная документация позволит быстро освоиться и использовать все возможности Subversion на полную мощность.

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

Система управления версиями Git.
(www.git-scm.com)

С февраля 2002 года для разработки ядра Linux’а большинством программистов стала использоваться система контроля версий BitKeeper. Довольно долгое время с ней не возникало проблем, но в 2005 году Лари МакВоем (разработчик BitKeeper’а) отозвал бесплатную версию программы.

Разрабатывать проект масштаба Linux без мощной и надежной системы контроля версий – невозможно. Одним из кандидатов и наиболее подходящим проектом оказалась система контроля версий Monotine, но Торвальдса Линуса не устроила ее скорость работы. Так как особенности организации Monatone не позволяли значительно увеличить скорость обработки данных, то 3 апреля 2005 года Линус приступил к разработке собственной системы контроля версий – Git.

Практически одновременно с Линусом (на три дня позже), к разработке новой системы контроля версий приступил и Мэтт Макал. Свой проект Мэтт назвал Mercurial, но об этом позже, а сейчас вернемся к распределенной системе контроля версий Git.

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

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

Часто при работе с Git создают центральный репозиторий, с которым остальные разработчики синхронизируются. Пример организации системы с центральным репозиторием – это проект разработки ядра Linux’a (http://www.kernel.org).

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

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

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

Можно долго обсуждать возможности Git’а, но для краткости и более простого восприятия приведем основные достоинства и недостатки этой системы управления версиями

Достоинства:

1. Надежная система сравнения ревизий и проверки корректности данных, основанные на алгоритме хеширования SHA1 (Secure Hash Algorithm 1).

2. Гибкая система ветвления проектов и слияния веток между собой.

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

4. Высокая производительность и скорость работы.

5. Удобный и интуитивно понятный набор команд.

6. Множество графических оболочек, позволяющих быстро и качественно вести работы с Git’ом.

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

8. Широкая распространенность, легкая доступность и качественная документация.

9. Гибкость системы позволяет удобно ее настраивать и даже создавать специализированные контроля системы или пользовательские интерфейсы на базе git.

10. Универсальный сетевой доступ с использованием протоколов http, ftp, rsync, ssh и др.

Недостатки:

1. Unix – ориентированность. На данный момент отсутствует зрелая реализация Git, совместимая с другими операционными системами.

2. Возможные (но чрезвычайно низкие) совпадения хеш - кода отличных по содержанию ревизий.

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

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

Выводы:

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

Система управления версиями Mercurial.
(mercurial.selenic.com)

Распределенная система контроля версий Mercurial разрабатывалась Мэттом Макалом параллельно с системой контроля версий Git, созданной Торвальдсом Линусом.

Первоначально, она была создана для эффективного управления большими проектами под Linux’ом, а поэтому была ориентирована на быструю и надежную работу с большими репозиториями. На данный момент mercurial адаптирован для работы под Windows, Mac OS X и большинство Unix систем.

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

Идентификация ревизий происходит на основе алгоритма хеширования SHA1 (Secure Hash Algorithm 1), однако, также предусмотрена возможность присвоения ревизиям индивидуальных номеров.

Так же, как и в git’е, поддерживается возможность создания веток проекта с последующим их слиянием.

Для взаимодействия между клиентами используются протоколы HTTP, HTTPS или SSH.

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

Рассмотрим основные достоинства и недостатки Mercurial.

Достоинства:

1. Быстрая обработка данных.

2. Кросплатформенная поддержка.

3. Возможность работы с несколькими ветками проекта.

4. Простота в обращение.

5. Возможность конвертирования репозиториев других систем поддержки версий, таких как CVS, Subversion, Git, Darcs, GNU Arch, Bazaar и др.

Недостатки:

1. Возможные (но чрезвычайно низкие) совпадения хеш - кода отличных по содержанию ревизий.

2. Ориентирован на работу в консоли.

Выводы:

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

Надежность и скорость работы позволяют использовать его для контроля версий огромных проектов. Все это делает mercurial достойным конкурентом git’а.

Система управления версиями Bazaar.
(bazaar.canonical.com)

Bazaar – распределенная, свободно распространяемая система контроля версий, разрабатываемая при поддержке компании Canonical Ltd. Написана на языке Python и работает под управлением операционных систем Linux, Mac OS X и Windows.

В отличие от Git и Mercurial, создаваемых для контроля версий ядра операционной системы Linux, а поэтому ориентированных на максимальное быстродействие при работе с огромным числом файлов, Bazaar ориентировался на удобный и дружественный интерфейс пользователя. Оптимизация скорости работы производилось уже на втором этапе, когда первые версии программы уже появились.

Как и во многих других системах контроля версий, система команд Bazaar’a - очень похожа на команды CVS или Subversion, что, впрочем, неудивительно, так как обеспечивает удобный, простой и интуитивно понятный интерфейс взаимодействия с программой.

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

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

Кратко приведем наиболее значительные достоинства и недостатки этой системы контроля версий.

Достоинства:

1. Кросплатформенная поддержка.

2. Удобный и интуитивно понятный интерфейс.

3. Простая работа с ветками проекта.

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

5. Великолепная документация.

6. Удобный графический интерфейс.

7. Чрезвычайная гибкость, позволяющая подстроится под нужды конкретного пользователя.

Недостатки:

1. Более низкая скорость работы, по сравнению с git и mercurial, но эта ситуация постепенно исправляется.

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

Выводы:

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

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

Arch – распределенная система контроля версий, созданная Томом Лордом. Изначально она создавалась для решения проблем CVS, что им вполне удалось.

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

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

Не требует специального сервиса для сетевого репозитория и может использовать такие протоколы, как FTP, SFTP или WebDAV и так далее.

Но, к сожалению, поддерживается только UNIX – системами, однако, перевод Arch под другие операционные системы не должен составлять труда.

Трудно отметить какие то принципиально лучшие качества, по сравнению с другими распределенным системами контроля версий, такими как git, mercurial, bazaar, так что если есть выбор, то лучше использовать что-то более мощное и распространенное.

Система управления версиями Perforce.
(www.perforce.com)

Продолжим обзор систем контроля версий и перейдем к коммерческим программам. Начнем с централизованной системы контроля версий – Perforce, разработанной компанией Perforce Software.

Система Perforce имеет клиент-серверную организацию и позволяет одновременно управлять несколькими проектами, создавая для каждого проекта свой репозиторий.

Perforce – кроссплатформенная система. Существуют версии, способные работать под управлением операционных систем Unix, Mac OS X, Microsoft Windows.

Для работы с системой контроля версий можно использовать, как консоль, так и специально разработанный графический интерфейс.

Серьезное преимущество Perforce’у дает возможность интегрироваться со множеством средств разработки программного обеспечения и такими приложениями, как Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs и многими другими.

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

Система управления версиями Team Foundation Server.
(msdn.microsoft.com/en-us/library/ms364061.aspx)

Собственно говоря, нельзя назвать Team Foundation Server (TFC) просто системой контроля версий – это некое комплексное решение, в состав которого входит и система управления версиями, и система сбора данных, и построения отчетов, и другие полезные функции.

Управляемый проект при работе с TFC представляет собой ветки исходного кода проекта, наборы отчетов и пользовательские элементы. При создании проекта заранее выбираются его параметры, которые можно, как выбирать самостоятельно, так и использовать шаблоны. Шаблоны позволяют определить путь развития проекта, сделать его гибким или жестко формализованным, заложить стратегию развития, учесть необходимые заготовки документов и отчетов.

TFC легко интегрируется с Microsoft Excel и Microsoft Project, что значительно облегчает создание и отслеживание элементов контролируемых проектов.

В качестве системы контроля версий, TFC позволяет:

Совместно корректировать файлы проекта;

Разрешать конфликты;

Создавать ветки проектов, а затем объединять их;

Управлять доступом к репозиторию;

Откатываться на предыдущие версии;

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

Помечать отдельные версии файлов в репозитории и группировать их;

Для сохранения данных и репозиториев разрабатываемых проектов используются базы данных SQL Server 2005.

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

Обобщение.

Большой выбор систем контроля версий позволяет удовлетворить любые требования и организовать работу так, как вам необходимо. Однако, среди всего многообразия систем есть явные лидеры. Так, если необходимо управлять огромным проектом, состоящим из десятков тысяч файлов и над которым работу ведут тысячи человек, то лучше всего выбор остановить на Git или Mercurial. Если для вас главное – удобный интерфейс, а разрабатываемый проект - не очень большой, то для вас предпочтительна система Bazaar.

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

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

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

Кроме того, Subversion требует дополнительное дисковое пространство для того, чтобы избежать сетевых запросов при выполнении некоторых операций: поиск модифицированных файлов (status) и отображение изменений (diff). В результате рабочая копия Subversion такого же размера (а то и больше) как репозиторий Mercurial и рабочий каталог вместе взятые, хотя репозиторий Mercurial содержит полную историю проекта.

Subversion имеет широкую поддержку инструментария сторонних производителей. В этом отношении у Mercurial сейчас существенное отставание. Хотя разрыв сокращается, и некоторые GUI-утилиты для Mercurial превосходят свои аналоги для Subversion. Как и Mercurial, Subversion располагает отличным руководством пользователя.

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

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

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

1.6.2. Git

Git - распределенная система контроля версий, которая была разработана для управления исходным кодом ядра Linux. Как и в случае с Mercurial, на начальный дизайн системы оказал влияние Monotone.

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

Что касается производительности - Git очень быстр. В некоторых случаях он быстрее, чем Mercurial (по крайней мере под Linux), а в других быстрее оказывается Mercurial. Однако под Windows как производительность, так и общий уровень поддержки, во время написания этой книги у Git гораздо хуже, чем у Mercurial.

В то время как репозиторий Mercurial не требует операций по техническому обслуживанию, репозиторий Git требует частых ручных «перепаковок » собственных метаданных. Если этого не делать, производительность начинает падать, наряду с увеличением объёма занимаемого дискового пространства. Дисковый массив сервера, содержащего несколько Git репозиториев, по отношению к которым не выполняется строгое правило частой «перепаковки » , рано или поздно забивается под завязку, в результате чего процесс ежедневного резервного копирования легко может занимать более 24 часов. Только что «запакованный » репозиторий Git занимает немного меньше места, чем репозиторий Mercurial, но объём не перепакованного репозитория будет на несколько порядков больше.

Ядро Git написано на языке С. Многие команды Git реализованы в виде Shell скриптов или скриптов на языке Perl и уровень качества данных скриптов сильно разнится. Я встречал несколько установок, в которых скрипты тупо продолжали выполнение, несмотря на наличие фатальных ошибок.

Mercurial предоставляет возможность импорта истории версий из репозитория Git.

1.6.3. CVS

CVS, наверное, самая широко распространённая система контроля версий в мире. Благодаря почтенному возрасту, а также бардаку, царящему внутри, он очень слабо поддерживается уже много лет.

CVS основан на централизованной, клиент-серверной архитектуре. Он не выполняет группировку файловых изменений в атомарные коммиты, тем самым позволяя людям легко «сломать билд » : один человек может успешно внести часть изменений в репозиторий, а затем оказаться заблокированным из-за необходимости выполнения слияния. Это приведёт к ситуации, когда остальные участники увидят только часть из тех изменений, которые они должны были увидеть. Данная особенность также влияет на то, как вы будете работать с историей изменений. Если вы хотите получить все изменения, которые один из членов команды внёс для решения определённой задачи, вам необходимо вручную исследовать описания и дату внесения изменений, произведённых для каждого затрагиваемого файла (если вы вообще знаете, какие файлы были затронуты).

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

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

«

1.8. Краткая история контроля версий

Самая известная из старых утилит контроля версий - SCCS (Source Code Control System, система контроля исходного кода), которую написал Марк Рочкайнд (Marc Rochkind) из Bell Labs, в начале 70-х. SCCS оперировала отдельными файлами и требовала, чтобы каждый человек, работающий над проектом, имел доступ к общему рабочему пространству, существовавшему в единственном экземпляре. Только один человек мог одновременно редактировать файл в один момент времени; конфликты доступа к файлам разрешались блокировками. Обычной ситуацией было забывание снятия блокировки после редактирования, что запрещало доступ к файлу другим людям без помощи администратора.

Вальтер Тичи (Walter Tichy) разработал свободную альтернативу SCCS в начале 1980-х; он назвал свою программу RCS (Revision Control System, система контроля ревизий). Подобно SCCS, RCS требовала от разработчиков как работы в едином разделяемом рабочем пространстве, так и блокировки файлов для предотвращения одновременного изменения файлов разными людьми.

Позднее, в 1980-х же годах, Дик Грюн (Dick Grune) использовал RCS как основу для набора shell-скриптов, изначально названных cmt, а позднее переименованных в CVS (Concurrent Versions System, система одновременных версий). Крупное нововведение CVS заключалось в том, что она позволяла разработчикам работать одновременно и, в некоторой степени, независимо в их личных рабочих пространствах. Этими-то пространствами и предотвратились постоянные наступания разработчиков друг другу на пятки, которое было обычным делом в SCCS и RCS. Каждый разработчик имел копию каждого файла проекта, разработчики могли модифицировать свои копии независимо. Им приходилось объединять собственные правки только перед отсылкою изменений в центральное хранилище.

Брайан Берлинер (Brian Berliner) взял первоначальные скрипты Грюна и переписал их на Си, выпустив в 1989 году код, который впоследствии развился в современную версию CVS. CVS в дальнейшем приобрела возможность работать по сети, обретя клиент-серверную архитектуру. Архитектура CVS является централизованной: только на сервере есть копия истории проекта. Клиентские рабочие копии содержали только экземпляры файлов последней версии и небольшие метаданные для определения местонахождения сервера. Система CVS достигла небывалого успеха: вероятно, она является самой широко используемой системой контроля версий в мире.

В начале 1990-х годов Sun Microsystems разработала раннюю распределённую систему контроля версий, называвшуюся TeamWare. Каждая рабочая копия TeamWare содержала полную копию истории изменений проекта. Понятие центрального репозитория в TeamWare отсутствовало как таковое. (Подобно CVS, использовавшей RCS для хранения истории, TeamWare использовала SCCS.)

Шли 1990-ые, росла осведомлённость о нескольких проблемах CVS. Система записывает одновременные изменения нескольких файлов раздельно, а не группирует их в одну логически атомарную операцию. Способ управления файловой иерархией не очень хорош: нетрудно устроить в репозитории беспорядок, переименовывая файлы и каталоги. Более того, исходные коды CVS непросто понимать и поддерживать, что сделало практически непреодолимым «болевой порог » исправления этих архитектурных проблем.

В 2001 году Джим Бланди (Jim Blandy) и Карл Фогель (Karl Fogel) - два разработчика, прежде работавшие над CVS - начали проект по её замене таким средством, которое имело бы архитектуру получше и код почище. Результат - Subversion - не отошёл от централизованной клиент-серверной модели CVS, но добавил атомарные коммиты нескольких файлов, лучшее управление пространствами имён и другие возможности, которые сделали Subversion более удобным средством работы, нежели CVS. Со времени выхода первой версии Subversion быстро обретал популярность.

Более или менее одновременно, Грейдон Хоар (Graydon Hoare) начал работать над амбициозной системой контроля версий, которую назвал Monotone. Эта система не только устраняет множество проблем внутреннего устройства CVS и имеет распределённую архитектуру, но и идёт далее нескольких прежних (и последующих) систем контроля версий в некоторых своих нововведениях. Monotone использует криптографические хеши в качестве идентификаторов и имеет неотъемлемое представление о «доверии » коду из различных источников.

Жизнь Mercurial началась в 2005 году. В то время как некоторые аспекты его архитектуры были созданы под влиянием Monotone, Mercurial сосредоточен на простоте использования, высокой производительности и масштабируемости до очень больших проектов.