Эволюция систем контроля версий

Я помню, как в 2005 году впервые познакомился с системой контроля версий. Это был CVS. Клиентом для него была коммандная строка, никакой графики, каждому файлу присваивалась отдельная ревизия. Оглядываясь назад, я бы сказал, что лучше использовать архивы чем, такую VCS, но тогда это было круто. Сейчас уже другое время и другие средства контроля версий, и мне стало интересно проследить как менялся подход к разработке и как это отражалось на VCS.

Файлы

Наверное, я всё-таки соврал. Первой программой, хранившей изменения кода, которой я пользовался, была среда разработки Delphi 7. Она не имела полноценной системы контроля версий, но была функция, котороя я находил похожее применение.

Delphi 7 IDE
Delphi 7 IDE

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

CVS

Я выпустился из школы, поступил в университет и устроился на работу. Над проектом уже работал не один человек, и возникала необходимость организации совместной работы. На дворе стоял 2005 год. Самой распространённой системой контроля версий на тот момент был CVS — Concurrent Versions System.

CVS. Concurrent Versions System.
Concurrent Versions System.

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

Subversion

Время шло и технологии развивались. Спустя почти 20 лет, свет увидел новую систему контроля версий под названием Subversion, она же SVN.

Subversion
Subversion

Subversion – на мой взгляд, это в основном существенное улучшение CVS: транзакционность фиксации изменений, возможность сохранения версий структуры проекта и т.д. Более подробная таблица сравнения есть на wikipedia. Но было и изменение концепции: SVN хранит не историю каждого файла отдельно, а наборы изменений. Проект теперь представлялся не набором разрозненных фалов, а чем-то более структурированным. Таким образом, определенная версия в VCS фиксировала состояние всего проекта. Подобная возможность позволяла определять рабочий процесс опираясь на понятия Subversion. Так, чаще всего, разработки новой версии программы ведутся в отдельных ветках, а в головной ветке (master) хранятся версии конечного приложения. Каждая фиксация в головной ветке означает исправление ошибок и соотвествует процедуре выпуска новой минорной версии приложения. Слияние же ветки разработки в головную означает выход в свет новой мажорной версии. Казалось бы, о чём еще мечтать? Всё просто, понятно и легко автоматизируется, но и на этом прогресс не остановился.

Git

Во время бурного развития скриптовых языков, таких как PHP, Ruby, Python, выяснилось, что редко изменения одного рода ограничивались единственной фиксацией. (Я, действительно, вижу взаимосвязь этих явлений). С одной стороны, фиксация изменений не всегда проходила гладко, и необходимо было вносить дополнительные изменения, которые сами по себе никакой ценности не имели; с другой стороны, разработчики хотели фиксировать свои промежуточные результаты. Для решения первой задачи как нельзя лучше подходит механизм веток, объединяющих версии в наборы. (Сравните это решение с переходом от хранения изменений каждого файла в CVS к хранению множества однородных изменений группы файлов в SVN). Таким образом, необходимо было улучшать механизмы работы с ветками. Вторую задачу тоже можно решить с помощью веток, если дать возможность разработчику не хранить ветку в центральном хранилище или разрешить реорганизацию ревизий в локальной копии хранилища перед отправкой изменений в репозиторий. Именно такими я вижу предпосылки для создания распределённых систем контроля версий (DVCS), таких как Git и Mercurial. Они увидели свет в 2005 году, сразу после выпуска SVN, но широкую популярность обрели сравнительно недавно, так как первые версии этих программ страдали нестабильной работой и отсутсвием документации. В них существенно расширялись возможности работы с ветками по сравнению с Subversion. Также они обеспечивают относительную независимость от центрального репозитория, если он вообще есть :) .

Git
Git

В DVCS появляется организация фиксаций изменений. Фиксации объединяются в векти, которые несут дополонительную смысловую информацию. Например уровень готовности программы (devel, relese candidate, production). Как и в Subversion, в Git рекомендуется использовать головную ветку, чтобы хранить в ней стабильные состояния программы. Однако простота управления ветками позволяет держать не одну нестабильную ветку для разработки, а столько, сколько необходимо для удобной работы. Например, распространенная практика — для разработки независимых функций программы использовать разные ветки.

Будущее

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

А может, все будет по-другому?

Поделиться
This entry was posted in Programming and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>