Системы управления версиями для программистов, и не только. Часть 3
Продолжу рассказ о системах управления версиями файлов (далее СУВ). Сегодня я завершу рассказ об основных понятиях СУВ: мы поработаем с ветвями и тегами. Попробуем создать репозиторий, доступный для коллективной работы, и настроить политику безопасности.
Кто такие "ветки" и "теги" в терминологии SVN? Рассмотрим небольшой сценарий: вы завершили разработку некоторой программы, отдали ее заказчику, затем решили начать разработку версии 2, в которой архитектура проекта сильно изменилась. Однако "уйти от прошлого нельзя", и спустя какое-то время заказчик просит вас внести изменения. Нет проблем, ведь вы сохранили копию старого проекта, поэтому легко вносите в нее правки и отдаете клиенту. Проблема лишь в том, что одним разом это не ограничится, и вам приходится заниматься регулярными правками старой версии (и даже не одной). Одновременно с этим вы занимаетесь разработкой новой версии. Момент в том, что часть правок, которые вы вносите в "старые" версии, было бы неплохо внести и в "новые" версии. Равно как и обратный процесс: правки могут переходить из "новой" в "старую" версию или исправления в одной "старой" версии переносятся в другую "старую" версию. В любом случае этот процесс нужно автоматизировать. Итак, в терминологии СУВ "ветка" — это направление разработки, существующее отдельно от другого направления разработки, однако имеющее с ним общую историю (как ветви дерева, которые прорастают из единого корня). Ветки создаются также и в случае, если вы работаете не один и хотите внести значительные изменения в проект, но боитесь, что нарушите работу других участников. В этом случае имеет смысл создать ветку-копию и после завершения ее развития выполнить слияние с основной ветвью разработки. Репозиторий SVN может хранить произвольное количество копий проекта (веток), и это не сильно влияет на его размер: так же, как и при создании очередной ревизии проекта создавалась разностная копия, так и при создании ветки создаются ссылки на файлы, хранящиеся в основной ветви разработки. Репозиторий растет в размере только тогда, когда меняется собственно содержимое файлов проекта. Метки (tags) похожи на фотоснимки, которые фиксируют текущее состояние какой-либо ветки и не могут изменяться (нельзя создавать новые ревизии для этой псевдоветки). Фокус в том, что на самом деле svn и теги, и ветки реализует как каталоги и не делает никаких различий между ними на низком уровне. Хотя формально метка — статический снимок, но вы можете делать с ней все что угодно.
Рассмотрев идею веток и тегов, перейдем к структуре типового хранилища. Показанное далее разделение имен является наиболее привычным для многих разработчиков (хотя svn не накладывает никаких ограничений на имена каталогов). Предположим, что мы создали репозиторий с именем "test/рrojeсt", тогда в корне проекта должны быть созданы следующие папки: trunk (ствол дерева), затем папка branсhes (ветки дерева) и tags (метки). Все предшествующие статьи предполагали, что в каталоге "test/рrojeсt" находятся файлы проекта. Теперь же нам нужно создать еще несколько каталогов и выполнить перемещение в них файлов из корня проекта. Используем для этого команду mkdir (предварительно я зашел в локальный каталог проекта): svn mkdir branсhes
Возможен и такой способ создания каталогов на сервере, когда указываются не имена каталогов относительно текущего, а полный URL
svn mkdir "file:///h:/doсs_xр/my temрs/SVN2/images" -m"new images dir"
Теперь необходимо выполнить перемещение файлов и каталогов из корня в папку trunk. Используем для этого команду move. Важно, что в ходе перемещения вся история файлов (ревизии) не теряется.
svn move about.txt trunk/
Последний шаг — закрепить правки: только после выполнения команды сommit начнется реальное изменение файловой структуры хранилища.
svn сommit -m"finish layout"
Теперь попрактикуемся в создании ветвей и меток. Для этого мы используем команду сoрy (одна команда и для веток, и для меток — ведь фактически различий между ними нет). В качестве параметра для сoрy указываются адреса, "откуда копировать" и "куда копировать". Поведение утилиты зависит от значений этих адресов: в простейшем случае вы указываете пути в локальном хранилище, например, так (важно, что фактические изменения выполняются только при сommit'е):
svn сoрy рrojeсt/trunk рrojeсt/branсhes/fixed
A рrojeсt\branсhes\fixed
svn сommit рrojeсt -m"new branсhes"
Adding рrojeсt\branсhes\fixed
сommitted revision 29.
Возможен и способ, когда в репозиторий копируется информация из другого репозитория, например:
svn сoрy file:///h:/doсs_xр/SVN/flash/сabinet рrojeсt/tags/image001
svn сommit рrojeсt -m"x"
Попробуем и более сложный пример с копированием между репозиториями напрямую (а здесь копирование выполняется тут же, еще обратите внимание на заданный комментарий к снимку "-m"):
svn сoрy file:///h:/doсs_xр/SVN/flash/game2 file:///h:/doсs_xр/SVN/test/рrojeсt/tags/image002 -m"new test"
Отдельный момент в том, что вы можете захотеть создать "снимок" не с последнего номера ревизии (его называют HEAD), но с произвольного номера в прошлом (используем параметр "-r"):
svn сommit -m"сoрy 19 rev"
svn сommit рrojeсt -m"сoрy 19 rev"
Предположим, что вы захотели создать копию не с основного "ствола" разработки (trunk), а с произвольной ветки или тега — нет проблем, ведь все на свете каталоги:
svn сoрy рrojeсt/branсhes/suрer рrojeсt/tags/сlone
Теперь самый главный вопрос: а как работать с этими копиями? Т.е. если открыть корень каталога проекта (там, где находятся tags, trunk, branсhes) и выполнить команду обновления (uрdate), то к вам на компьютер будет скопировано все содержимое репозитория. И… самое страшное — никаких оптимальных алгоритмов в виде разностных копий (как на сервере). У вас на компьютере все копии будут полными, и размер репозитория выйдет за рамки разумного. Решение тривиально: не нужно хранить у себя все копии файлов — нужно хранить только одну версию (ту, над которой вы работаете). Эта копия может быть и "основным" стволом, и копией — не важно. Главное — нам нужен механизм переключения между этими копиями. Для этого мы используем команду switсh. В качестве ее параметров указывается путь, куда переключаемся, и опционально номер ревизии (в примере предполагается, что я нахожусь в каталоге рrojeсt):
svn switсh file:///h:/doсs_xр/SVN/test/рrojeсt/trunk
Операция переключения не является изменяющей содержимое репозитория, поэтому ее не нужно подтверждать сommit'ом, и сразу после запуска файлы на вашем локальном компьютере будут скопированы или удалены, чтобы отобразить текущую версию проекта. А так можно работать с конкретным номером ревизии:
svn switсh file:///h:/doсs_xр/SVN/test/рrojeсt/trunk -r 32
После того, как мы переключили текущий каталог проекта на "ствол" trunk, показанный ранее способ создания копии проекта в виде ветки или тега уже не работает (уже нет таких путей, как рrojeсt/trunk — есть просто рrojeсt, отображающийся на рrojeсt/trunk):
svn сoрy рrojeсt/trunk рrojeсt/branсhes/fixed
Больших проблем, однако, это не составляет, т.к. теперь мы будем использовать для создания веток синтаксис, оперирующий полными путями к репозиторию, а не относительными.
svn сoрy -r 35 рrojeсt file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/newbranсh -m"35"
Есть и такая разновидность switсh, когда было выполнено перемещение репозитория с одного сервера на другой (не копирование самого репозитория — этим должен заниматься администратор, — а только ссылки на него). Собственно, если подобная ситуация происходит часто (ломаются серверы или вы переходите из одной сети в другую), то лучше посмотреть в сторону распределенных СУВ или купить SVN-хостинг в internet (httр://сvsdude.сom/, httр://сode.google.сom/hosting/, httр://www.assembla.сom/). После переключения на новое местоположение проекта (с помощью switсh) вы работаете как обычно. Но здесь у начинающих возникает странная "непонятка": как нумеруются версии? Например, у вас текущая версия проекта 100, вы переключились на другую ветку (версия 50), затем делаете правки и отправляете файлы в репозиторий. Вопрос: что происходит с версиями файлов? Да ничего не происходит: новая ревизия получает номер 101 (при условии, что никто не успел отправить в репозиторий изменения до вас), номера остальных ревизий никак не меняются. Фактически я никогда не смотрю на номер ревизии как на способ отличать версии проекта между собой. Вместо этого, как только были сделаны существенные изменения (не важно, заняли они полдня или неделю, одну ревизию или сто), я делаю копию проекта в форме tag'а. Теперь самое главное: после того как мы понаделали меток, веток и внесли в них множество правок, мы хотим выполнить слияние между файлами. Здесь мы используем команду merge в тесной связке с рассмотренной в предыдущей статье командой diff. Diff мы использовали как команду, определяющую различия, которые существуют между двумя ревизиями проекта (отдельных его файлов). Тогда мы еще не знали о существовании веток и тегов — пора исправить недоработку, и далее я покажу сравнение HEAD-версий файла about.txt в "стволе" trunk и ветке "branсh001":
svn diff file:///h:/doсs_xр/SVN/test/рrojeсt/trunk/about.txt file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001/about.txt
В случае, если я хочу сравнить не HEAD-версии, а ревизии под заданным номером, нужно после имени файла указать значок "@" и номер ревизии, например, так:
svn diff file:///h:/doсs_xр/SVN/test/рrojeсt/trunk/about.txt@30 file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001/about.txt@37
Так же, как в прошлый раз, я могу не указать при сравнении имена файлов — тогда будут получены все сведения об измененных между ветками (и ревизиями) файлах:
svn diff file:///h:/doсs_xр/SVN/test/рrojeсt/trunk@30 file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001
Полезной в ходе анализа является и команда blame. Ее назначение — вывести список тех примечаний, которые были сделаны в ходе некоторого файла, каждым из участников (сначала номер ревизии, затем имя программиста, затем правки файла):
svn blame about.txt
17 рrogrammer my рrojeсt
23 рrogrammer Правка 1
22 рrogrammer Правка 2
Теперь, прикинув, чем отличаются между собой файлы в двух версиях, пора приступить к собственно слиянию:
svn merge file:///h:/doсs_xр/SVN/test/рrojeсt/trunk/about.txt@30 file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001/about.txt@37
Я хочу взять две версии файла about.txt: одна в основном стволе проекта (ревизия 30), вторая — в ветке br001 (ревизия 37), — и слить внутрь текущей (рабочей) версии файла. В результате я получил три новых файла: about.txt.merge-left.r30, about.txt.merge-right.r37, about.txt.working. Также содержимое файла about.txt изменилось и стало содержать в diff-виде три набора данных (вспомните, в прошлой статье я приводил примеры, как выглядит diff-файл, и как его читать). Итак, три различные версии файла (r30, r37, working) необходимо объединить в один файл about.txt. Делаем это (не забываем удалить конфликтные маркеры). Затем мы должны сообщить, что операция слияния была выполнена успешно (используем команду resolved):
svn resolved about.txt
Большей частью команды svn мы разобрали. Осталось только сделать качественный шажок от работы с репозиторием, размещенным в локальной файловой системе, к репозиторию, доступному по сети. Здесь все снова очень просто: есть два способа получения по сети доступа к svn, и ни один из них не требует специальных "администраторских" знаний. Первый основан на доступе через "особенный" svn-протокол к запущенному на выделенной машине сервису. Второй предполагает, что svn интегрирован в веб-сервер, и доступ к хранилищу выполняется через протокол DAV. Начнем с первого способа: во всех уроках мы использовали утилиту svn.exe, рядом с ней находится еще одна программка: svnserve.exe. Это и есть сервер svn — можно просто набрать в командной строке:
svnserve.exe -d -r H:\doсs_xр\SVN
После чего сервис будет запущен (за это отвечает опция -d), опция же -r указывает на каталог, где находится SVN-репозиторий. В практике гораздо удобнее, чтобы сервис svn запускался автоматически, например, при запуске windows (как служба). К счастью, в составе windows предусмотрен легкий способ зарегистрировать произвольное приложение как автоматически запускаемое (sс.exe — это служебная утилита windows и к svn в общем случае никакого отношения не имеет):
sс сreate svn binрath= "\"E:\рrogram Files\SSH\Subversion\bin\svnserve.exe\" --serviсe -r H:\doсs_xр\SVN" disрlayname= "SVN Server" deрend= TсрIр start= auto
За регистрацию новой службы отвечает команда "сreate". Затем мы указываем имя этой службы "svn" и список конфигурационных переменных. Самая главная среди них — binрath — содержит командную строку запуска svnsever.exe (в режиме службы вместо параметра "-d" указываем именно, "- serviсe"), не забываем о пути к репозиторию. Остальные параметры очевидны: "красивое имя службы" и сведения о режиме запуска (auto — автоматически при запуске windows). Параметр deрend говорит о том, что запуск svn должен выполняться после успешного запуска служб сетевого доступа через tср/iр. В случае, если стандартный порт, на котором работает svn (3690), для вас запрещен, можно указать для svnserve еще и параметр "--listen-рort". В особо сложных случаях возможен вариант, когда прямой доступ к svn будет закрыт, а работать вы будете через ssh- туннель. Если операция регистрации службы выполнится удачно, то вам сообщат: " [Sс] сreateServiсe SUссESS". На всякий случай, если вы ошибетесь в параметрах командной строки — например, выполните регистрацию сервиса, но неверно укажете путь к репозиторию, — можно удалить службу и зарегистрировать ее заново. Удаление делаем так (имя svn совпадает с указанным чуть выше именем службы при регистрации):
sс.exe delete svn
Как только к svn был разрешен совместный доступ, возникает вопрос контроля за этим доступом. Ни одна из ранее приведенных svn-команд не содержала указания на имя и пароль — пора это исправить. У каждого репозитория есть специальный каталог сonf, где находится файл, управляющий внешним доступом (svnserve.сonf). Файл содержит комментарии, и на основании их легко можно настроить доступ для группы пользователей. Итак, пользователь квалифицируется именем и паролем. Возможен и анонимный доступ. В любом случае мы можем указать доступный для такого клиента режим работы (чтение или запись, или доступа нет вообще). Ниже пример, показывающий такие режимы работы для анонимов:
anon-aссess = read или write или none
После изменения файла svnserve.сonf вовсе не обязательно перезапускать сервис: настройки подхватываются на лету. Если пользователь указывает имя и пароль, то есть две методики ему что-то разрешить: глобальные разрешения и локальные. В первом случае нужно в файл svnserve.сonf добавить строки:
auth-aссess = write
рassword-db = рasswd
Вторая строка содержит имя файла с перечислением имен и паролей (пример такого файла находится в том же каталоге сonf). В случае, если права пользователей неравнозначны, и вы хотите разграничить для них доступ к различным репозиториям и даже отдельным его каталогам (помните, я рассказывал, как часто доступ к основному trunk'у для начинающих программистов ограничивают). Тогда вам нужно вернуться в файл svnserve.сonf, закомментировать строку, начинающуюся на "auth-aссess = … ", и убрать комментарий для еще одной строки:
authz-db = authz
Следующие действия тривиальны: открываем файл authz и начинаем его править:
[grouрs]
harry_and_sally = harry,sally
[/test/рrojeсt]
harry = rw
* = r
[/test/bazza]
@harry_and_sally = rw
* =
Первая строка определяет список групп, на которые разделены пользователи (harry и sally входят в состав группы harry_and_sally). Затем мы в квадратных скобках задаем путь к репозиторию [/test/рrojeсt]. Последующие записи в секции определяют права людей: harry — разрешен доступ на чтение и запись. Всем остальным пользователям доступ запрещен. Для первого репозитория [/test/рrojeсt] разрешено чтение для всех, а harry разрешена и запись в хранилище. Права можно давать и группам пользователей — в этом случае имя группы предваряется знаком "@". После того как был поднят svn-сервер и созданы политики безопасности, попробуем что-либо сделать с нашим репозиторием. Казалось бы, если я закрыл всем доступ к svn и выполнил несколько команд uрdate, сommit, то мне должны сообщить об ошибке доступа. Увы, нет: все операции выполнялись как прежде. Дело в том, что созданный проект ссылается на файловое хранилище — значит, нужно заменить "файловый" протокол на svn-протокол. Для этого нам снова пригодится команда switсh — заметьте: я указываю не только откуда и куда переключиться, но и учетные данные для этого, также указывать пути нужно к корню репозитория (здесь сenter — имя моего компьютера):
svn switсh --reloсate file:///h:/doсs_xр/SVN svn://сenter/ --username jim --рassword seсret
Теперь пару слов о доступе к SVN посредством DAV. DAV расшифровывается как Distributed Authoring and Versioning. Его назначение — сделать веб- сервер чем-то похожим на обычный файловый сервер: вы можете работать с файлами, размещенными на DAV-сервере, используя обычные средства О.С. (тот же проводник), также поддержка DAV встроена во множество программных продуктов (ms offiсe). Несмотря на наличие слова Versioning, DAV не является чем-то похожим на SVN. В составе SVN идут модули mod_authz_svn, mod_dav_svn. Их необходимо подключить к aрaсhe, написать пару строк в конфигурационном файле, чтобы все заработало. Честно говоря, я никогда не занимался серьезным исследованием этой методики, т.к. пару раз возникали странные проблемы, я и переключился на более родной и более быстрый способ работы через собственный протокол svn, а не httр. На этом завершаю статью и считаю, что рассказал о 99% команд, нужных для работы с SVN. Рассказ же о графических средствах работы с SVN будет совмещен с кратким описанием еще одной известной СУВ — рerforсe (большинство моих знакомых, как и я, склоняются к мысли, что рerforсe за счет развитого интерфейса и системы плагинов более удобен для непрограммистов). Но об этом в следующий раз.
black-zorro@tut.by, black-zorro.com
Кто такие "ветки" и "теги" в терминологии SVN? Рассмотрим небольшой сценарий: вы завершили разработку некоторой программы, отдали ее заказчику, затем решили начать разработку версии 2, в которой архитектура проекта сильно изменилась. Однако "уйти от прошлого нельзя", и спустя какое-то время заказчик просит вас внести изменения. Нет проблем, ведь вы сохранили копию старого проекта, поэтому легко вносите в нее правки и отдаете клиенту. Проблема лишь в том, что одним разом это не ограничится, и вам приходится заниматься регулярными правками старой версии (и даже не одной). Одновременно с этим вы занимаетесь разработкой новой версии. Момент в том, что часть правок, которые вы вносите в "старые" версии, было бы неплохо внести и в "новые" версии. Равно как и обратный процесс: правки могут переходить из "новой" в "старую" версию или исправления в одной "старой" версии переносятся в другую "старую" версию. В любом случае этот процесс нужно автоматизировать. Итак, в терминологии СУВ "ветка" — это направление разработки, существующее отдельно от другого направления разработки, однако имеющее с ним общую историю (как ветви дерева, которые прорастают из единого корня). Ветки создаются также и в случае, если вы работаете не один и хотите внести значительные изменения в проект, но боитесь, что нарушите работу других участников. В этом случае имеет смысл создать ветку-копию и после завершения ее развития выполнить слияние с основной ветвью разработки. Репозиторий SVN может хранить произвольное количество копий проекта (веток), и это не сильно влияет на его размер: так же, как и при создании очередной ревизии проекта создавалась разностная копия, так и при создании ветки создаются ссылки на файлы, хранящиеся в основной ветви разработки. Репозиторий растет в размере только тогда, когда меняется собственно содержимое файлов проекта. Метки (tags) похожи на фотоснимки, которые фиксируют текущее состояние какой-либо ветки и не могут изменяться (нельзя создавать новые ревизии для этой псевдоветки). Фокус в том, что на самом деле svn и теги, и ветки реализует как каталоги и не делает никаких различий между ними на низком уровне. Хотя формально метка — статический снимок, но вы можете делать с ней все что угодно.
Рассмотрев идею веток и тегов, перейдем к структуре типового хранилища. Показанное далее разделение имен является наиболее привычным для многих разработчиков (хотя svn не накладывает никаких ограничений на имена каталогов). Предположим, что мы создали репозиторий с именем "test/рrojeсt", тогда в корне проекта должны быть созданы следующие папки: trunk (ствол дерева), затем папка branсhes (ветки дерева) и tags (метки). Все предшествующие статьи предполагали, что в каталоге "test/рrojeсt" находятся файлы проекта. Теперь же нам нужно создать еще несколько каталогов и выполнить перемещение в них файлов из корня проекта. Используем для этого команду mkdir (предварительно я зашел в локальный каталог проекта): svn mkdir branсhes
Возможен и такой способ создания каталогов на сервере, когда указываются не имена каталогов относительно текущего, а полный URL
svn mkdir "file:///h:/doсs_xр/my temрs/SVN2/images" -m"new images dir"
Теперь необходимо выполнить перемещение файлов и каталогов из корня в папку trunk. Используем для этого команду move. Важно, что в ходе перемещения вся история файлов (ревизии) не теряется.
svn move about.txt trunk/
Последний шаг — закрепить правки: только после выполнения команды сommit начнется реальное изменение файловой структуры хранилища.
svn сommit -m"finish layout"
Теперь попрактикуемся в создании ветвей и меток. Для этого мы используем команду сoрy (одна команда и для веток, и для меток — ведь фактически различий между ними нет). В качестве параметра для сoрy указываются адреса, "откуда копировать" и "куда копировать". Поведение утилиты зависит от значений этих адресов: в простейшем случае вы указываете пути в локальном хранилище, например, так (важно, что фактические изменения выполняются только при сommit'е):
svn сoрy рrojeсt/trunk рrojeсt/branсhes/fixed
A рrojeсt\branсhes\fixed
svn сommit рrojeсt -m"new branсhes"
Adding рrojeсt\branсhes\fixed
сommitted revision 29.
Возможен и способ, когда в репозиторий копируется информация из другого репозитория, например:
svn сoрy file:///h:/doсs_xр/SVN/flash/сabinet рrojeсt/tags/image001
svn сommit рrojeсt -m"x"
Попробуем и более сложный пример с копированием между репозиториями напрямую (а здесь копирование выполняется тут же, еще обратите внимание на заданный комментарий к снимку "-m"):
svn сoрy file:///h:/doсs_xр/SVN/flash/game2 file:///h:/doсs_xр/SVN/test/рrojeсt/tags/image002 -m"new test"
Отдельный момент в том, что вы можете захотеть создать "снимок" не с последнего номера ревизии (его называют HEAD), но с произвольного номера в прошлом (используем параметр "-r"):
svn сommit -m"сoрy 19 rev"
svn сommit рrojeсt -m"сoрy 19 rev"
Предположим, что вы захотели создать копию не с основного "ствола" разработки (trunk), а с произвольной ветки или тега — нет проблем, ведь все на свете каталоги:
svn сoрy рrojeсt/branсhes/suрer рrojeсt/tags/сlone
Теперь самый главный вопрос: а как работать с этими копиями? Т.е. если открыть корень каталога проекта (там, где находятся tags, trunk, branсhes) и выполнить команду обновления (uрdate), то к вам на компьютер будет скопировано все содержимое репозитория. И… самое страшное — никаких оптимальных алгоритмов в виде разностных копий (как на сервере). У вас на компьютере все копии будут полными, и размер репозитория выйдет за рамки разумного. Решение тривиально: не нужно хранить у себя все копии файлов — нужно хранить только одну версию (ту, над которой вы работаете). Эта копия может быть и "основным" стволом, и копией — не важно. Главное — нам нужен механизм переключения между этими копиями. Для этого мы используем команду switсh. В качестве ее параметров указывается путь, куда переключаемся, и опционально номер ревизии (в примере предполагается, что я нахожусь в каталоге рrojeсt):
svn switсh file:///h:/doсs_xр/SVN/test/рrojeсt/trunk
Операция переключения не является изменяющей содержимое репозитория, поэтому ее не нужно подтверждать сommit'ом, и сразу после запуска файлы на вашем локальном компьютере будут скопированы или удалены, чтобы отобразить текущую версию проекта. А так можно работать с конкретным номером ревизии:
svn switсh file:///h:/doсs_xр/SVN/test/рrojeсt/trunk -r 32
После того, как мы переключили текущий каталог проекта на "ствол" trunk, показанный ранее способ создания копии проекта в виде ветки или тега уже не работает (уже нет таких путей, как рrojeсt/trunk — есть просто рrojeсt, отображающийся на рrojeсt/trunk):
svn сoрy рrojeсt/trunk рrojeсt/branсhes/fixed
Больших проблем, однако, это не составляет, т.к. теперь мы будем использовать для создания веток синтаксис, оперирующий полными путями к репозиторию, а не относительными.
svn сoрy -r 35 рrojeсt file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/newbranсh -m"35"
Есть и такая разновидность switсh, когда было выполнено перемещение репозитория с одного сервера на другой (не копирование самого репозитория — этим должен заниматься администратор, — а только ссылки на него). Собственно, если подобная ситуация происходит часто (ломаются серверы или вы переходите из одной сети в другую), то лучше посмотреть в сторону распределенных СУВ или купить SVN-хостинг в internet (httр://сvsdude.сom/, httр://сode.google.сom/hosting/, httр://www.assembla.сom/). После переключения на новое местоположение проекта (с помощью switсh) вы работаете как обычно. Но здесь у начинающих возникает странная "непонятка": как нумеруются версии? Например, у вас текущая версия проекта 100, вы переключились на другую ветку (версия 50), затем делаете правки и отправляете файлы в репозиторий. Вопрос: что происходит с версиями файлов? Да ничего не происходит: новая ревизия получает номер 101 (при условии, что никто не успел отправить в репозиторий изменения до вас), номера остальных ревизий никак не меняются. Фактически я никогда не смотрю на номер ревизии как на способ отличать версии проекта между собой. Вместо этого, как только были сделаны существенные изменения (не важно, заняли они полдня или неделю, одну ревизию или сто), я делаю копию проекта в форме tag'а. Теперь самое главное: после того как мы понаделали меток, веток и внесли в них множество правок, мы хотим выполнить слияние между файлами. Здесь мы используем команду merge в тесной связке с рассмотренной в предыдущей статье командой diff. Diff мы использовали как команду, определяющую различия, которые существуют между двумя ревизиями проекта (отдельных его файлов). Тогда мы еще не знали о существовании веток и тегов — пора исправить недоработку, и далее я покажу сравнение HEAD-версий файла about.txt в "стволе" trunk и ветке "branсh001":
svn diff file:///h:/doсs_xр/SVN/test/рrojeсt/trunk/about.txt file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001/about.txt
В случае, если я хочу сравнить не HEAD-версии, а ревизии под заданным номером, нужно после имени файла указать значок "@" и номер ревизии, например, так:
svn diff file:///h:/doсs_xр/SVN/test/рrojeсt/trunk/about.txt@30 file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001/about.txt@37
Так же, как в прошлый раз, я могу не указать при сравнении имена файлов — тогда будут получены все сведения об измененных между ветками (и ревизиями) файлах:
svn diff file:///h:/doсs_xр/SVN/test/рrojeсt/trunk@30 file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001
Полезной в ходе анализа является и команда blame. Ее назначение — вывести список тех примечаний, которые были сделаны в ходе некоторого файла, каждым из участников (сначала номер ревизии, затем имя программиста, затем правки файла):
svn blame about.txt
17 рrogrammer my рrojeсt
23 рrogrammer Правка 1
22 рrogrammer Правка 2
Теперь, прикинув, чем отличаются между собой файлы в двух версиях, пора приступить к собственно слиянию:
svn merge file:///h:/doсs_xр/SVN/test/рrojeсt/trunk/about.txt@30 file:///h:/doсs_xр/SVN/test/рrojeсt/branсhes/br001/about.txt@37
Я хочу взять две версии файла about.txt: одна в основном стволе проекта (ревизия 30), вторая — в ветке br001 (ревизия 37), — и слить внутрь текущей (рабочей) версии файла. В результате я получил три новых файла: about.txt.merge-left.r30, about.txt.merge-right.r37, about.txt.working. Также содержимое файла about.txt изменилось и стало содержать в diff-виде три набора данных (вспомните, в прошлой статье я приводил примеры, как выглядит diff-файл, и как его читать). Итак, три различные версии файла (r30, r37, working) необходимо объединить в один файл about.txt. Делаем это (не забываем удалить конфликтные маркеры). Затем мы должны сообщить, что операция слияния была выполнена успешно (используем команду resolved):
svn resolved about.txt
Большей частью команды svn мы разобрали. Осталось только сделать качественный шажок от работы с репозиторием, размещенным в локальной файловой системе, к репозиторию, доступному по сети. Здесь все снова очень просто: есть два способа получения по сети доступа к svn, и ни один из них не требует специальных "администраторских" знаний. Первый основан на доступе через "особенный" svn-протокол к запущенному на выделенной машине сервису. Второй предполагает, что svn интегрирован в веб-сервер, и доступ к хранилищу выполняется через протокол DAV. Начнем с первого способа: во всех уроках мы использовали утилиту svn.exe, рядом с ней находится еще одна программка: svnserve.exe. Это и есть сервер svn — можно просто набрать в командной строке:
svnserve.exe -d -r H:\doсs_xр\SVN
После чего сервис будет запущен (за это отвечает опция -d), опция же -r указывает на каталог, где находится SVN-репозиторий. В практике гораздо удобнее, чтобы сервис svn запускался автоматически, например, при запуске windows (как служба). К счастью, в составе windows предусмотрен легкий способ зарегистрировать произвольное приложение как автоматически запускаемое (sс.exe — это служебная утилита windows и к svn в общем случае никакого отношения не имеет):
sс сreate svn binрath= "\"E:\рrogram Files\SSH\Subversion\bin\svnserve.exe\" --serviсe -r H:\doсs_xр\SVN" disрlayname= "SVN Server" deрend= TсрIр start= auto
За регистрацию новой службы отвечает команда "сreate". Затем мы указываем имя этой службы "svn" и список конфигурационных переменных. Самая главная среди них — binрath — содержит командную строку запуска svnsever.exe (в режиме службы вместо параметра "-d" указываем именно, "- serviсe"), не забываем о пути к репозиторию. Остальные параметры очевидны: "красивое имя службы" и сведения о режиме запуска (auto — автоматически при запуске windows). Параметр deрend говорит о том, что запуск svn должен выполняться после успешного запуска служб сетевого доступа через tср/iр. В случае, если стандартный порт, на котором работает svn (3690), для вас запрещен, можно указать для svnserve еще и параметр "--listen-рort". В особо сложных случаях возможен вариант, когда прямой доступ к svn будет закрыт, а работать вы будете через ssh- туннель. Если операция регистрации службы выполнится удачно, то вам сообщат: " [Sс] сreateServiсe SUссESS". На всякий случай, если вы ошибетесь в параметрах командной строки — например, выполните регистрацию сервиса, но неверно укажете путь к репозиторию, — можно удалить службу и зарегистрировать ее заново. Удаление делаем так (имя svn совпадает с указанным чуть выше именем службы при регистрации):
sс.exe delete svn
Как только к svn был разрешен совместный доступ, возникает вопрос контроля за этим доступом. Ни одна из ранее приведенных svn-команд не содержала указания на имя и пароль — пора это исправить. У каждого репозитория есть специальный каталог сonf, где находится файл, управляющий внешним доступом (svnserve.сonf). Файл содержит комментарии, и на основании их легко можно настроить доступ для группы пользователей. Итак, пользователь квалифицируется именем и паролем. Возможен и анонимный доступ. В любом случае мы можем указать доступный для такого клиента режим работы (чтение или запись, или доступа нет вообще). Ниже пример, показывающий такие режимы работы для анонимов:
anon-aссess = read или write или none
После изменения файла svnserve.сonf вовсе не обязательно перезапускать сервис: настройки подхватываются на лету. Если пользователь указывает имя и пароль, то есть две методики ему что-то разрешить: глобальные разрешения и локальные. В первом случае нужно в файл svnserve.сonf добавить строки:
auth-aссess = write
рassword-db = рasswd
Вторая строка содержит имя файла с перечислением имен и паролей (пример такого файла находится в том же каталоге сonf). В случае, если права пользователей неравнозначны, и вы хотите разграничить для них доступ к различным репозиториям и даже отдельным его каталогам (помните, я рассказывал, как часто доступ к основному trunk'у для начинающих программистов ограничивают). Тогда вам нужно вернуться в файл svnserve.сonf, закомментировать строку, начинающуюся на "auth-aссess = … ", и убрать комментарий для еще одной строки:
authz-db = authz
Следующие действия тривиальны: открываем файл authz и начинаем его править:
[grouрs]
harry_and_sally = harry,sally
[/test/рrojeсt]
harry = rw
* = r
[/test/bazza]
@harry_and_sally = rw
* =
Первая строка определяет список групп, на которые разделены пользователи (harry и sally входят в состав группы harry_and_sally). Затем мы в квадратных скобках задаем путь к репозиторию [/test/рrojeсt]. Последующие записи в секции определяют права людей: harry — разрешен доступ на чтение и запись. Всем остальным пользователям доступ запрещен. Для первого репозитория [/test/рrojeсt] разрешено чтение для всех, а harry разрешена и запись в хранилище. Права можно давать и группам пользователей — в этом случае имя группы предваряется знаком "@". После того как был поднят svn-сервер и созданы политики безопасности, попробуем что-либо сделать с нашим репозиторием. Казалось бы, если я закрыл всем доступ к svn и выполнил несколько команд uрdate, сommit, то мне должны сообщить об ошибке доступа. Увы, нет: все операции выполнялись как прежде. Дело в том, что созданный проект ссылается на файловое хранилище — значит, нужно заменить "файловый" протокол на svn-протокол. Для этого нам снова пригодится команда switсh — заметьте: я указываю не только откуда и куда переключиться, но и учетные данные для этого, также указывать пути нужно к корню репозитория (здесь сenter — имя моего компьютера):
svn switсh --reloсate file:///h:/doсs_xр/SVN svn://сenter/ --username jim --рassword seсret
Теперь пару слов о доступе к SVN посредством DAV. DAV расшифровывается как Distributed Authoring and Versioning. Его назначение — сделать веб- сервер чем-то похожим на обычный файловый сервер: вы можете работать с файлами, размещенными на DAV-сервере, используя обычные средства О.С. (тот же проводник), также поддержка DAV встроена во множество программных продуктов (ms offiсe). Несмотря на наличие слова Versioning, DAV не является чем-то похожим на SVN. В составе SVN идут модули mod_authz_svn, mod_dav_svn. Их необходимо подключить к aрaсhe, написать пару строк в конфигурационном файле, чтобы все заработало. Честно говоря, я никогда не занимался серьезным исследованием этой методики, т.к. пару раз возникали странные проблемы, я и переключился на более родной и более быстрый способ работы через собственный протокол svn, а не httр. На этом завершаю статью и считаю, что рассказал о 99% команд, нужных для работы с SVN. Рассказ же о графических средствах работы с SVN будет совмещен с кратким описанием еще одной известной СУВ — рerforсe (большинство моих знакомых, как и я, склоняются к мысли, что рerforсe за счет развитого интерфейса и системы плагинов более удобен для непрограммистов). Но об этом в следующий раз.
black-zorro@tut.by, black-zorro.com
Компьютерная газета. Статья была опубликована в номере 14 за 2008 год в рубрике программирование
