ЛЕКЦИЯ 8. Системы контроля версий.

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

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

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

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

Соответствующие команды: svn checkout (забрать последнюю версию), svn resolve (показать, что конфликт в исходном коде разрешен) и svn commit (создать в репозитарии очередную ревизию).

Некоторые системы контроля версий являются также и системами управления конфигурацией программ (software configuration management - SCM). Такие системы специально созданы для управления деревьями исходного кода, и имеют множество возможностей, специфичных для разработки программ, таких как непосредственное понимание языков программирования, или предоставление инструментов для сборки программ. Однако Subversion не является такой системой, она является системой общего назначения, которая может быть использована для управления любым набором файлов, включая и исходные коды программ.

Хранилище (репозитарий).

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

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

Когда клиент читает данные из хранилища, он обычно видит только последнюю версию дерева файловой системы. Но клиент также имеет возможность просмотреть предыдущие состояния файловой системы. Например, клиент может запросить такие данные как, «Что содержал этот каталог в прошлую среду?» или «Кто последним изменял этот файл и какие изменения он произвёл?» Вопросы подобного типа являются основными для любой системы управления версиями: системы, разработанной для записи и отслеживания изменений информации во времени.

Проблема совместного использования файлов.

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

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

Модель Блокирование-Изменение-Разблокирование.

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

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

• Блокирование может вызвать административные проблемы. Иногда Гарри, заблокировав файл, забывает об этом. Между тем, поскольку Салли всё ещё ждёт, когда она сможет приступить к редактированию файла, её руки связаны. А потом Гарри уезжает в отпуск. Теперь Салли для снятия блокировки Гарри должна обратиться к администратору. Ситуация приводит к ненужной задержке и потере времени.

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

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

Модель Копирование-Изменение-Слияние.

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

Вот пример: скажем, и Гарри, и Салли создали свои рабочие копии одного и того же проекта, скопировав их из хранилища. Они работают одновременно, и делают изменения в файле A в своих рабочих копиях. Первой свои изменения в хранилище сохраняет Салли. Затем, когда Гарри пытается сохранить свои изменения, хранилище информирует его, что его файл А устарел. Другими словами, файл А в хранилище был как-то изменён с тех пор, как Гарри получил его. Поэтому Гарри просит своего клиента слить (merge) любые изменения из хранилища с его рабочей копией файла А. Возможно, что изменения Салли не пересекаются с его собственными, и, поскольку теперь в его рабочей копии объединены оба набора изменений, он записывает её обратно в хранилище.

Но что будет, если изменения Салли всё-таки пересекаются с изменениями Гарри? Что происходит в этом случае? Эта ситуация, называемая конфликтом, обычно не такая уж большая проблема. Когда Гарри просит объединить свои изменения с изменениями из хранилища, его копия файла А помечается как находящаяся в состоянии конфликта: он имеет возможность видеть оба набора конфликтующих изменений, и вручную выбирать между ними. Обратите внимание, программа не может автоматически разрешать конфликты, только человек способен понять и сделать необходимый осмысленный выбор. Когда Гарри вручную разрешил пересекающиеся изменения (возможно, путём их обсуждения с Салли!), он может безопасно сохранить объединённый файл обратно в хранилище.

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

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

> Subversion и TortoiseSVN.

Адреса для доступа к хранилищу.

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

Метод доступа file:// обычно используется для локального доступа, хотя он может быть использован с путями UNC для доступа к узлам по сети. В этом случае URL имеет форму file://имя-компьютера/путь/к/хранилищу. Для локальной машины часть имя-компьютера должна быть либо пропущена, либо указана как localhost. По этой причине, локальные пути обычно указывают с тремя косыми чертами (/), file:///путь/к/хранилищу.

Организация данных в хранилище.

Есть несколько стандартных рекомендуемых способов организации хранилища. Большинство людей создают папку trunk, в которой ведётся «основная линия» разработки, папку branches, содержащую копии ответвлений, и папку tags для копий меток. Если хранилище содержит только один проект, тогда их часто создают как папки верхнего уровня.

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

Для реорганизации папок и файлов внутри репозитория можно использовать «Обозреватель репозитория».