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

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

Немного теории

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

Система контроля версий - это специальное программное обеспечение, предназначенное для одновременного хранения нескольких версий одного и того же файла, определения изменений, внесенных в новые версии, возвращения в случае возникновения такой необходимости к более новым версиям и массы других вещей, связанных с изменениями документов в течение времени. Кстати говоря, термин "система контроля версий", можно сказать, не совсем точный, поскольку является калькой с английского "Version Control System". Правильным переводом данного словосочетания на русский язык будет "система управления версиями". Впрочем, именно правильный термин почему-то на просторах бывшего Советского Союза прижился хуже, и чаще всего используют термин "система контроля версий". Ну и, естественно, английские аббревиатуры VCS и RCS (последняя происходит от "Revision Control System").

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

Централизованные системы контроля версий

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

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

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

Распределённые системы

Но, кроме централизованных систем контроля версий, есть и распределённые, которые не сгребают все файлы в кучу в своё хранилище на сервере, а хранят их прямо на пользовательских компьютерах. Обычно вместе с теми файлами, которые редактирует этот конкретно взятый пользователь, хранятся ещё и все остальные - то есть, копия хранилища присутствует во всей своей полноте на каждом пользовательском компьютере. Чем это удобно? Тем, что у вас есть куча "бэкапов" всего хранилища, которые создаются автоматом и не требуют никакого автоматического администрирования. Ещё пользователи VCS мало зависят от гримас связи, что удобно для распределённых команд. Ну а самое неудобное здесь даже не то, что для хранения базы всех файлов нужно много места - хотя иногда и это становится проблемой. Но настоящая проблема - синхронизация разных версий файлов в хранилищах у разных разработчиков.

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

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

Кто они, наши герои?

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

Вообще-то, конечно, систем управления версиями существует великое множество - как централизованных, так и распределённых, как коммерческих, так и свободных. Среди централизованных наиболее известные, пожалуй, CVS (Concurrent Versions System) и SVN, она же Subversion. Обе они являются по совместительству ещё и свободными. CVS сегодня большинством разработчиков считается устаревшей, и вместо неё как раз и советую использовать SVN. В пользу Subversion говорит тот факт, что её применяют в таких крупных проектах, как Mono, FreeBSD, GCC и других. Ну а разных мелких проектов и компаний, где используется эта система управления версиями, и вовсе не счесть. Из коммерческих систем нужно, в первую очередь, вспомнить Microsoft Visual SourceSafe - не менее уважаемый, чем Subversion, программный продукт. У Microsoft (ну кто бы сомневался) есть ещё один программный продукт, включающий в себя функционал системы контроля версий, - это Team Foundation Server. Из распределенных систем, в первую очередь, вспоминаются Mercurial, Git (написанная в своё время ещё самим Линусом Торвальдсом) и Bazaar. Они все тоже свободные, что, наверное, и способствует их большой популярности и широкому распространению по всему миру.

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

Вадим СТАНКЕВИЧ,
[email protected]