Интернет магазин китайских планшетных компьютеров

Компьютеры - Subversion - Основные концепции

Файловая система

Рис. 1. Двумерное представление файловой системы в Subversion

С точки зрения пользователя хранилище Subversion представляет собой «двумерную» файловую систему. Объекты в хранилище идентифицируются двумя «координатами»: именем и номером ревизии. Другими словами, хранилище представляет собой массив мгновенных снимков дерева файлов и директорий, индексируемый номером ревизии. Каждый такой снимок — обычная файловая система.

При необходимости указания на конкретную ревизию объекта используется запись вида: имя@ревизия, например, /main.c@29 — файл /main.c в ревизии 29. Такое указание ревизии, используемое для уточнения имени, называется стержневая ревизия.

На рис. 1 показано графическое представление файловой системы: вертикальная ось соответствует множеству имён, горизонтальная — множеству ревизий.

Имена файлов

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

Номера ревизий

Номер ревизии в Subversion — это натуральное число, адресующее номер состояния хранилища в процессе изменения содержащихся в нём данных. Каждая успешная фиксация изменений порождает ровно одну новую ревизию в хранилище, то есть N-я ревизия — это состояние хранилища после N-й фиксации.

В Subversion ревизия характеризует состояние не отдельного файла, а всего хранилища в целом. Например, ревизия 32 — это состояние трёх файлов и двух директорий, существовавших в хранилище на тот момент.

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

• Минимальный номер ревизии 0 соответствует изначальному состоянию хранилища, когда ещё не было зафиксировано ни одной правки. В нулевой ревизии хранилище содержит только пустую корневую директорию.
• Максимальный номер ревизии соответствует самому последнему состоянию хранилища, то есть состоянию после фиксации последней правки. Вместо указания номера последней ревизии можно использовать ключевое слово HEAD; это удобно, поскольку номер головной ревизии увеличивается при каждой фиксации изменений.

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

Оперативная и стержневая ревизии

Рис. 2. Указание стержневой ревизии

Номер ревизии используется в двух различных контекстах:

• оперативной ревизии;
• стержневой ревизии.

Ревизия называется оперативной, если она указывается как ревизия или диапазон ревизий, к которому должна быть применена команда, например:

svn log -r 199:230 http://some.path

В данном примере выполняется команда svn log для диапазона ревизий 199:230, который и является диапазоном оперативных ревизий.

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

svn log -r 29:33 http://some.path/bar.txt

В команде указан диапазон оперативных ревизий, но области, выделенные на рисунке голубым и зелёным фоном, в равной степени можно считать историей файла /bar.txt в диапазоне ревизий 29:33. В подобных случаях необходимо указывать ещё и стержневую ревизию для разрешения неоднозначности. Стержневая ревизия — это номер ревизии, указанный в дополнение к URL объекта файловой системы. URL со стержневой ревизией всегда однозначно идентифицирует объект. Команда применяется к той единственной цепочке состояний, которой принадлежит указанная пара URL@ревизия. В приведённом ниже примере первая команда выведет историю, выделенную на рисунке голубым фоном, а вторая — историю, выделенную зелёным фоном:

svn log -r 29:33 http://some.path/file.txt@32
svn log -r 29:33 http://some.path/bar.txt@34

В качестве стержневой ревизии следует указывать как можно более позднее состояние интересующего объекта. Причина этого в том, что цепочка состояний однозначно отслеживается «назад», но не «вперёд». Например, URL со стержневой ревизией http://some.path/foo.txt@31 принадлежит двум цепочкам состояний. Из этих двух цепочек указанный URL адресует серую цепочку, то есть при движении «вперёд» от стержневой ревизии операции копирования игнорируются.

Операции над файловой системой

Над объектами файловой системы в хранилище Subversion могут быть произведены перечисленные ниже операции. В скобках указано краткое именование операции в обозначениях команды svn status.

• Добавление. Добавление объекта в файловую систему. Добавленный объект не имеет истории ревизий. Пример на рисунке:

• файл /main.c был добавлен в ревизии 27.

• Модификация. Модификация объекта, например, изменение содержимого файла или изменение свойств файла или директории. Пример на рисунке:

• файл /main.c был модифицирован в ревизии 28.

• Удаление. Удаление файла из головной и последующих ревизий. При этом файл остаётся в предыдущих ревизиях. Пример на рисунке:

• файл /main.c был удалён в ревизии 30.

• Добавление с историей. Представляет собой копирование объекта внутри файловой системы хранилища, то есть объект имя_источника@ревизия_источника копируется в имя_копии@HEAD. Скопированный объект наследует от источника историю ревизий до момента копирования. Примеры на рисунке:

• в ревизии 29 директория /tags/R1 была скопирована с директории /trunk@27;
• в ревизии 31 файл /main.c был скопирован с /main.c@29, то есть с более ранней ревизии самого себя, таким образом, произведено восстановление ранее удалённого файла с сохранением истории ревизий.

• Замена. Имеет место в случае, когда в одной ревизии произведено и удаление объекта, и добавление с историей объекта с тем же самым именем. Хотя имя при операции замены остаётся неизменным, Subversion рассматривает объект до и после замены как два различных объекта с различными историями ревизий. Пример на рисунке:

• в ревизии 30 файл /file.txt был заменён: старый файл /file.txt удалён, а новый файл с тем же именем скопирован с файла /bar.txt@29.

Фиксация изменений

Рабочая копия

Рабочая копия — это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая помимо собственно данных некоторую служебную информацию. Служебная информация необходима для правильного функционирования рабочей копии; что-либо менять в служебных данных нельзя. Минимальной единицей данных, которую можно получить из хранилища как рабочую копию, является директория. Другими словами, в Subversion рабочая копия всегда соответствует ровно одной директории хранилища. Извлечь из хранилища отдельный файл как рабочую копию невозможно.

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

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

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

Транзакции

Работа с хранилищем в Subversion организована в форме транзакций со свойствами атомарности и изоляции из набора свойств ACID. Таким образом система управления версиями гарантирует целостность, непротиворечивость и доступность хранилища в любой момент времени.

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

Рабочая копия Subversion, в отличие от хранилища, при сбое может оказаться в промежуточном или заблокированном состоянии.

Локальные и удалённые формы команд

Все команды клиента Subversion можно разделить на следующие группы:

• модифицирующие рабочую копию;
• модифицирующие хранилище;
• модифицирующие и рабочую копию, и хранилище;
• не модифицирующие ничего.

Структура хранилища

Структура проекта в хранилище

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

/.

trunk

branches

tags

где вся файловая структура проекта должна содержаться в поддиректории trunk, поддиректория branches должна содержать ветви проекта, а tags — метки. Например, следующая структура директорий хранилища:

/.

trunk

branches

branch_1

tags

tag_1

tag_2

предполагает наличие у проекта одной ветви «branch_1» и двух меток «tag_1» и «tag_2». Каждая из этих директорий содержит копию соответствующей версии проекта.

Еслипроектов в хранилище несколько, то такая структура поддиректорий создается для каждогопроекта:

/.

project1

trunk

branches

tags

project2

trunk

branches

tags

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

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

Ветви

Subversion использует «файловую» модель для реализации ветвей и меток, то есть ветвь является обычной директорией. Новая ветвь создаётся командой svn copy. Ветвь может быть создана в любой директории хранилища, однако имеет смысл придерживаться описанных выше соглашений о том, где создавать новые ветви. Более подробная информация о ветвях приведена в разделах Ветвление и Слияние.

Метки

Создание метки также производится командой svn copy, то есть технически не отличается от создания ветви. Отличие только в способе использования: предполагается, что никто не будет изменять данные в метке. Например, на рис. 1 метка создана в ревизии 29: директория /trunk из ревизии 27 скопирована под именем /tags/R1. Теперь, если не изменять данные в директории /tags/R1, то она навсегда останется точной копией директории /trunk@27, то есть будет меткой.

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

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

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

Недостатки:

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

Свойства

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

Свойства объектов файловой системы

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

Свойства файлов

svn:executable 

Делает файл исполняемым.

svn:mime-type 

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

svn:keywords 

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

svn:eol-style 

Определяет правило преобразования символов конца строки в текстовом файле. Используется в случаях, когда файл должен иметь конкретный тип символов EOL. Обычно используется «native» — при этом тип символов конца строки соответствует принятому в той операционной системе, в которой происходит создание рабочей копии.

svn:needs-lock 

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

svn:special 

Свойство не предназначено для установки или модификации пользователями. В настоящее время используется для хранения символьных ссылок в репозитории. Когда символьная ссылка добавляется в репозиторий, в репозитории создаётся файл с установленным свойством svn:special. Когда этот файл извлекается в UNIX-подобной системе, клиентская программа Subversion преобразует его обратно в ссылку.

svn:mergeinfo 

Хранит информацию о том, из каких путей было произведено слияние в этот файл. Свойство введено в версии 1.5, оно используется для отслеживания слияний. Представляет собой набор строк вида имя_файла:диапазон_ревизий. Здесь имя_файла — полное имя файла или директории, откуда было произведено слияние указанного диапазона ревизий. Строки модифицируются автоматически при операциях слияния; при последующих слияниях Subversion учитывает ранее вписанные строки, избегая тем самым повторных слияний одних и тех же изменений. Не рекомендуется изменять свойство svn:mergeinfo вручную — это может нарушить механизм отслеживания слияний.

Свойства директорий

svn:ignore 

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

svn:externals 

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

svn:mergeinfo 

То же, что и для файлов.

Свойства ревизий

Второй тип объектов, для которых существуют свойства, — это сами ревизии. В этом случае имена свойств также могут быть любыми; некоторые свойства с префиксом «svn:» имеют специальное значение. Отличие свойств ревизий от свойств объектов файловой системы в том, что для первых понятие истории версий не применимо. Другими словами, свойства ревизий можно изменить, но старое значение при этом теряется. По умолчанию изменение свойств ревизий запрещено; для разрешения администратор должен создать скрипт обработки события pre-revprop-change.

svn:date 

Дата и время создания ревизии.

svn:author 

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

svn:log 

Описание изменений, зафиксированных в этой ревизии.

Как правило, свойства ревизий изменяются только администратором хранилища в целях исправления некорректных данных. Например, если пользователь забыл указать текстовое описание при фиксации своих изменений, то администратор может создать это описание путём редактирования свойства svn:log.