Заметки по работе с SVN

Материал из rrv-wiki
Перейти к навигации Перейти к поиску

Допустим имеем сервер http://svn.rrv.ru/

Делаем импорт в SVN

Для этого делаем в репозитории папку scripts:

svn mkdir http://svn.rrv.ru/scripts

если мы имеем учетную запись на сервере с доступом в svn-репозитарий то можно воспользоваться протоколом ssh

svn mkdir svn+ssh://svn.rrv.ru/home/svn/scripts

Делаем import, например у нас есть например папка со скриптами ~/bin, тогда:

svn import ~/bin http://svn.rrv.ru/scripts

Теперь в svn папка есть наша папка, но локальная копия по прежнему чиста, делаем backup на всякий случай

mv ~/bin ~/bin-back

теперь чтобы у нас была локальная копия с репозитария нужно сделать checkout:

svn checkout http://svn.rrv.ru/scripts ~/bin

теперь у нас есть локальная копия скриптов с репозитория внутри которой есть служебная информация для команды svn

Повседневное использование

Считаем что мы пользуемся один репозиторием.

Редактируем существующий файл

редактируем какой нибудь файл

vi ~/bin/test.pl

для проверки статуса (не обязательно) пишем:

svn status ~/bin

она покжет:

M ~/bin/test.pl 

т.е. файл модифицирован Заливаем на сервер:

svn commit ~/bin/test.pl

или аналогично, но для всей папки

svn commit ~/bin/

все, теперь у нас и локальная копия и копия на svn-сервере одинаковые

Добавление файла

Если мы редактируем файл которого не было.

vi ~/bin/new.pl

то svn commit ~/bin этот файл не затронет, т.к. сервер не знает что за этим файлом нужно следить (т.е. он вне системы контроля версий) нужно его добавить:

svn add ~/bin/new.pl

Теперь он помечен для добавления

svn commit ~/bin/new.pl

добавит реально его в репозиторий

Добавление папки

аналогично добавлению файла:

svn add ~/bin/newdir
svn commit ~/bin/newdir

Добавление нескольких файлов находящихся в одной папке

аналогично добавлению файла:

svn add ~/bin/newdir/*

будет ругатся на существующие файлы, но это мы игнорируем

svn commit ~/bin/newdir

Восстановление файла из локального хранилища

Допустим мы испортили файл ~/bin/test.pl, тогда его можно восстановить из локальной копии:

svn revert ~/bin/test.pl

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

Совместная работа

Перед началом работы делаем на рабочей копии репозитория обновление:

svn update ~/bin/

Далее если при выполнении svn update возникнут конфликты, то большую часть из них svn решит сам, но если конфликт неразрешим силами и при выполнении svn update он скажет что у тебя например конфликт в ~/bin/test.pl, то при этом у тебя будут 3 файла:

  1. ~/bin/test.pl.mine (наша последняя копия)
  2. ~/bin/test.pl.rev30 (та ревизия до которую мы редактировали)
  3. ~/bin.test.pl.rev34 (та ревизия которую мы слили последней)

Просматривая 3 файла, редактируем ~/bin/test.pl как считаем нужным потом выполняем

svn resolved ~/bin/test.pl 

и все эти файлы пропадают, svn считает что мы разрешили этот конфликт.

Проверка статуса рабочей версии файлов и директорий

Для проверки состояния используем:

svn status ~/bin/

подробный help:

svn help status

Краткий справочник svn (subversion)

взято здесь

svn checkout svn+ssh://repository.url/svn/name — извлекаем файлы проекта из репозитория, сокращение: svn co;
svn update — получаем обновления из репозитория, сокращение: svn up;
svn update -r rev_num ./file_name — извлекаем ревизию файла с номером rev_num;
svn add ./file_name — добавляем файл в репозиторий (не важно текстовый или бинарный);
svn rename ./old_file_name ./new_file_name — переименовываем файл в репозитории;
svn remove ./file_name — удаляем файл/директорию из репозитория;
svn status — просматриваем локально измененные файлы, сокращение: svn st;
svn status -u — просматриваем локально измененные и изменившиеся в репозитории файлы, сокращение: svn st -u;
svn diff ./file_name — показывает локальные изменения в файле построчно;
svn diff -r rev_num1:rev_num2 ./file_name — показывает различия между ревизией rev_num1 и rev_num2 файла;
svn revert ./file_name — откатывает локальные изменения файла (выгружает из репозитория последнюю закоммиченную ревизию);
svn revert -R ./ — откатывает все локальные изменения файлов;
svn log ./file_name — список ревизий с комментариями;
svn blame ./file_name — показывает авторов изменений файла построчно, синоним: svn annotate;
svn propset svn:ignore ./file_name . — добавляем файл в список игнорируемых файлов;
svn propset svn:keywords "Id Author Date" ./file_name — установка атрибутов файла;
svn cleanup — снимает блокировки с файлов;
svn unlock svn+ssh://repository.url/svn/file_name — снять блокировку файла (URL можно узнать с помощью команды svn info ./file_name | grep URL, его и нужно передавать в svn unlock);
svnadmin setlog --bypass-hooks /path/to/repository -r rev_num ./commit_text_file — заменяет текстовое описание коммита, где rev_num — номер ревизии, commit_text_file — путь к файлу, содержащему новый комментарий к коммиту;
svn help command_name — выводит помощь по команде command_name, например, «svn help update»;
svn merge -r rev_to_rollback:rev_good ./file_name — откатываем ревизию номер rev_to_rollback до ревизии rev_good, причем все изменения старше rev_to_rollback сохраняются (Например, у файла есть ревизии 11,12 и 13. Хотим откатить 12-ую ревизию, но так, что бы изменения 13-ой остались в силе. Делаем тогда так: svn merge -r 12:11 ./file_name);
svn copy svn+ssh://repository.url/svn/name/trunk/ svn+ssh://repository.url/svn/name/branches/new_branch_name/ — создаем ветку с названием new_branch_name из главной линии разработки;
svn merge --dry-run -r rev_num1:rev_num2 svn+ssh://repository.url/svn/name/trunk/ — проверяем, что будет изменено при объединении веток, где rev_num1 — номер ревизии, когда ваша ветка была «открыта», или это м.б. номер предыдущего объединения (слияния), rev_num2 — версия главной линии разработки, с которой производим объединение. Необходимо отметить, что все изменения будут применены для директории, в которой выполнялась эта команда;
svn merge -r rev_num1:rev_num2 svn+ssh://repository.url/svn/name/trunk/ — синхронизирует вашу ветку с главной линией разработки с учетом ревизий: rev_num1 — номер ревизии, когда ваша ветка была «открыта», или это м.б. номер предыдущего объединения (слияния), rev_num2 — версия главной линии разработки, с которой производим объединение. Необходимо отметить, что все изменения будут применены для директории, в которой выполнялась эта команда;