Рабочие копии
Вы уже читали о рабочих копиях; теперь мы покажем как Subversion-клиент создает и использует их.
Рабочая копия Subversion представляет собой обычное дерево каталогов на вашем компьютере, содержащее набор файлов. Вы можете по-своему усмотрению редактировать эти файлы и, если это исходные коды, вы можете обычным способом скомпилировать программу. Ваша рабочая копия это ваше личное рабочее пространство: Subversion как не смешивает вносимые другими изменения с вашими, так и не делает доступными для других изменения сделанные вами, пока вы не прикажете сделать это. Вы даже можете иметь несколько рабочих копий одного и того же проекта.
После того, как вы внесли изменения в файлы вашей рабочей копии и убедились в том, что они корректно работают, Subversion предлагает вам команды «публикации» (записи в хранилище) ваших изменений, в результате чего они станут доступными для всех участников проекта. Если другие участники проекта опубликовали свои изменения, Subversion предлагает вам команды для объединения (путем чтения информации из хранилища) этих изменений с вашей рабочей копией.
Рабочая копия содержит несколько дополнительных файлов, созданных и обслуживаемых Subversion, которые помогают ей при выполнении этих команд. В частности, каждый каталог в вашей рабочей копии содержит подкаталог с именем .svn который называется служебным каталогом рабочей копии. Файлы в служебном каталоге помогают Subversion определить какие файлы рабочей копии содержат неопубликованные изменения, и какие файлы устарели по отношению к файлам других участников.
Как правило, хранилище Subversion содержит файлы (или исходный код) нескольких проектов; обычно каждый проект представляется в виде подкаталога файловой системы хранилища. При таком подходе, пользовательская рабочая копия обычно соответствует отдельному подкаталогу хранилища.
Например, предположим, что у вас есть хранилище, содержащее два программных проекта: paint и calc. Каждый проект располагается в своем собственном каталоге, как показано на Рисунок 2.6, «Файловая система хранилища».
Рисунок 2.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.
URL хранилища
Получить доступ к хранилищу Subversion можно различными способами — на локальном диске или через ряд сетевых протоколов. Местоположение хранилища всегда определяется при помощи URL. Таблица Таблица 2.1, «URL для доступа к хранилищу.» показывает соответствие разных URL-схем возможным методам доступа.
Таблица 2.1. URL для доступа к хранилищу.
| file:/// | прямой доступ к хранилищу (на локальном диске) |
| http:// | доступ через протокол WebDAV (если Subversion-сервер работает через Apache) |
| https:// | тоже что и http:// но с SSL-шифрованием |
| svn:// | доступ через собственный протокол к серверу svnserve |
| svn+ssh:// | тоже что и svn://, но через SSH-соединение |
Подробнее о том, как Subversion обрабатывает URL, см. в «Subversion Repository URLs».
Предположим, вы внесли изменения в button.c. Так как каталог .svn помнит дату изменения файла и его оригинальное содержимое, Subversion может сказать о том, что вы изменили файл. Subversion не публикует ваших изменений пока вы не прикажете это сделать. Публикация ваших изменений более известна как фиксация (или checking in) изменений в хранилище.
Для того, что бы опубликовать ваши изменения вы можете воспользоваться командой commit:
$ svn commit 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, а также информацию из хранилища.
