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

$ svn checkout http://svn.example.com:9834/repos
…

Однако, в обработке URL системой Subversion есть некоторые нюансы, о которых нужно помнить. Например, в соответствии с принятыми соглашениями, URL, использующий метод доступа file: (этот метод доступа используется для локальных хранилищ), должен либо включать имя сервера localhost, либо вообще не содержать имени сервера:

$ svn checkout file:///path/to/repos
…
$ svn checkout file://localhost/path/to/repos
…

Кроме того, тем, кто применяет схему file: на платформе Windows, необходимо использовать неофициальные «стандартные» правила записи при обращении к хранилищу, которое находится на одном компьютере, но на разных дисках с клиентом. Обе приведенные ниже записи будут работать; здесь X — это имя диска, на котором находится хранилище:

C:\> svn checkout file:///X:/path/to/repos
…
C:\> svn checkout "file:///X|/path/to/repos"
…

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

Ну и наконец, нужно сказать о том, что клиент Subversion при необходимости автоматически кодирует URL точно так же, как это делает веб-браузер. Например, если URL будет содержать пробел или ASCII-символы в верхнем регистре:

$ svn checkout "http://host/path with space/project/españa"

…то Subversion скроет небезопасные символы и будет вести себя так, как будто вы напечатали:

$ svn checkout http://host/path%20with%20space/project/espa%C3%B1a

Если в URL есть пробелы, возьмите его в кавычки, и тогда командная оболочка обработает это все как один аргумент программы svn.

Вы уже читали о рабочих копиях; теперь мы покажем как клиент Subversion создает и использует их.

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

После того, как вы внесли изменения в файлы вашей рабочей копии и убедились в том, что они корректно работают, Subversion предлагает вам команды «публикации» (записи в хранилище) ваших изменений, в результате чего они станут доступными для всех участников проекта. Если другие участники проекта опубликовали свои изменения, Subversion предлагает вам команды для объединения (путем чтения информации из хранилища) этих изменений с вашей рабочей копией.

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

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

Например, предположим, что у вас есть хранилище, содержащее два программных проекта: paint и calc. Каждый проект располагается в своем собственном каталоге как показано на Рисунок 1.6, «Файловая система хранилища».

Для того, чтобы создать рабочую копию, вам нужно получить какой-либо из подкаталогов хранилища. (Возможно, термин получить звучит как что-то, связанное с блокированием или резервированием ресурсов, но это не так; данная команда просто создает для вас личную копию проекта.) Например, если вы получите /calc, у вас будет рабочая копия наподобие этой:

$ svn checkout http://svn.example.com/repos/calc
A    calc/Makefile
A    calc/integer.c
A    calc/button.c
Checked out revision 56.

$ ls -A calc
Makefile  integer.c  button.c  .svn/

Буквы А говорят о том, что Subversion добавил этот элемент в вашу рабочую копию. Теперь у вас есть личная копия каталога /calc хранилища, с одним небольшим добавлением — каталогом .svn, содержащим, как было указано выше, дополнительную информацию, необходимую Subversion.

Предположим, вы внесли изменения в button.c. Так как каталог .svn помнит дату изменения файла и его оригинальное содержимое, Subversion может сказать о том, что вы изменили файл. Subversion не публикует ваших изменений, пока вы не прикажете это сделать. Публикация ваших изменений более известна как фиксация (или checking in) изменений в хранилище.

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

$ svn commit button.c -m "Fixed a typo in button.c."
Sending        button.c
Transmitting file data .
Committed revision 57.

Теперь ваши изменения в button.c, вместе с примечанием, описывающим эти изменения (а именно: исправление опечатки), зафиксированы в хранилище; если другой пользователь создаст рабочую копию /calc, он увидит ваши изменения в последней версии файла.

Предположим, у вас есть партнер, Салли, которая создала рабочую копию /calc одновременно с вами. Когда вы зафиксировали изменения в button.c, рабочая копия Салли осталась неизмененной, так как Subversion модифицирует рабочие копии только по запросу пользователей.

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

$ pwd
/home/sally/calc

$ ls -A
.svn/ Makefile integer.c button.c

$ svn update
U    button.c
Updated to revision 57.

Вывод команды svn update говорит, что Subversion обновила содержимое button.c. Обратите внимание, что Салли не должна указывать, какой файл обновить; для определения файлов, которые необходимо привести в актуальное состояние, Subversion использует информацию в каталоге .svn, а также информацию из хранилища.

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

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

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

Рисунок 1.7, «Хранилище» отлично иллюстрирует хранилище. Представьте массив номеров правок, начинающийся с 0, с направлением слева направо. Каждый номер правки имеет соответствующее дерево файлов, а каждое дерево представляет собой «снимок» того, как хранилище выглядело после фиксации.

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

calc/Makefile:4
     integer.c:4
     button.c:4

На данный момент рабочий каталог полностью соответствует правке 4 в хранилище. Допустим, что вы внесли изменения в button.c и зафиксировали эти изменения. При отсутствии других фиксаций ваша фиксация создаст правку под номером 5, и теперь ваша рабочая копия выглядит следующим образом:

calc/Makefile:4
     integer.c:4
     button.c:5

Предположим, что после этого Салли фиксирует изменения integer.c, создавая правку 6. Если вы воспользуетесь svn update для приведения своей рабочей копии в актуальное состояние, то она станет выглядеть так:

calc/Makefile:6
     integer.c:6
     button.c:6

Изменения, внесенные Салли в integer.c будут отражены в вашей рабочей копии, и ваши изменения в button.c также будут присутствовать. В этом примере текст Makefile в правках 4, 5 и 6 идентичен, однако Subversion проставляет номер правки 6 для вашей рабочей копии Makefile, чтобы показать что файл не устарел. Таким образом, после того как вы выполните полное обновление вашей рабочей копии, она будет полностью соответствовать текущему состоянию хранилища.

В служебном каталоге .svn/ для каждого файла рабочего каталога Subversion записывает информацию о двух важнейших свойствах:

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

Может показаться, что следить за актуальным состоянием рабочей копии сложно. Это не так. Для того, чтобы узнать состояние любого элемента в вашей рабочей копии, существует команда svn status. За более подробной информацией об этой команде обратитесь к «svn status».

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