Краткая шпаргалка по основным командам Subversion
Не могу сказать, что я большой фанат Subversion. По-моему, Git прекрасен, и никакие другие системы контроля версий не нужны. Тем не менее, работать с Subversion время от времени приходится, потому что нужно сделать checkout какого-то древнего полумертвого проекта или еще почему-то. Так что, в этой заметке мы рассмотрим основы работы с Subversion, ну и заодно почему он иногда может быть даже интереснее, чем Git. Заметка рассчитана на тех, кто уже имеет опыт использования Git или хотя бы Mercurial.
Перекрестная ссылка: Вас также может заинтересовать старенькая заметка Мой первый опыт работы с Subversion. Там речь идет больше про настройку серверной стороны, а также про использование всяких TortoiseSVN и прочих GUI. Данный же пост посвящен работе с уже существующими репозиториями из консоли.
Итак, почему же Subversion иногда может быть интереснее, чем Git:
- Считается, что централизованную систему контроля версий проще объяснить новичкам;
- Используются последовательные номера ревизий, ясно что за чем шло;
- Тут можно чекаутить отдельные каталоги и делать для них свои бранчи;
- Есть поддержка file lock, что иногда, пожалуй, может быть удобно;
- Subversion лучше работает с бинарными файлами и компактно хранит их дифы;
Я, впрочем, не гугу Subversion. Но в первом приближении, вроде, все верно.
Теперь перейдем к командам.
Делаем checkout:
svn co --username eax https://example.com/project/trunk/
Подсасываем последние изменения:
svn up
Проверить, в какой ветке мы находимся и на какой сервер смотрим:
svn info
Посмотреть историю изменений:
svn up
svn log | less
История изменений с diff’ами, аналог git log -p:
svn log --diff | less
Кто какие строчки когда менял:
svn blame -v test.txt
Посмотреть незакомиченные изменения:
svn diff
Какие файлы были изменены или добавлены:
svn diff --summarize
Изменения в рамках ревизиции, аналог git show:
# посмотреть комментарий
svn log -c 123456
# посмотреть изменения
svn diff -c 123456
Посмотреть измененные в ревизии файлы:
svn diff --summarize -c 123456
Изменения по сравнению с текущей ревизией, аналог git diff:
svn diff -r 123456
svn diff --summarize -r 123456
Применение сохраненного в файл дифа, аналог git apply:
patch -p0 -i myfile.diff
Отменить последние изменения, аналог git reset --hard HEAD:
svn revert --recursive .
Текущее состояние репозитория, измененные файлы и так далее:
svn status
Удалить неотслеживаемые файлы и каталоги – встроенной команды, увы, нет, но можно прописать алиас в .bashrc:
svn status | perl -lne 'if(/^\?\s+(.*?)$/){ print $1 }' | xargs rm -r
Получение списка бранчей:
svn ls https://example.com/project/branches/
Создание нового бранча или тэга:
svn copy https://example.com/project/trunk/ \
https://example.com/project/branches/test-branch
svn copy https://example.com/project/trunk/ \
https://example.com/project/tags/1.0 \
-m "Release 1.0"
Переключение на бранч:
cd path/to/trunk
cd ..
mkdir branches
cd branches
svn co https://example.com/project/branches/test-branch
cd test-branch
Мерж бранча:
svn merge http://example.ru/project/branches/test-branch
Удаление бранча:
svn delete http://example.ru/project/branches/test-branch \
-m "Removing test-branch"
Примечание: Примите также во внимание, что если вы сделали checkout самого корня репозитория, в котором находятся каталоги trunk, branches и tags, то можете просматривать бранчи обычным ls, удалять обычным svn rm с последующим коммитом, и так далее. Впрочем, в больших проектах вы вряд ли захотите делать checkout вот прямо всего репозитория целиком.
Добавить файл:
svn add text.txt
Переименовать файл:
svn mv from.txt to.txt
Удалить файл:
svn del file.txt
Lock/unlock, чтобы файл никто не мог менять кроме нас:
svn lock file.txt
svn unlock file.txt
Коммит и сразу пуш, потому что это SVN:
svn commit -m 'Your comment here'
В общем-то, описанных команд вам хватит в 95% всех случаев. Дополнительную информацию рекомендую искать в man’ах и help’ах. Еще можно порекомандовать книгу Pragmatic Version Control using Subversion.
А пользуетесь ли вы Subversion и если да, то какие команды советовали бы добавить к приведенному выше списку?
Дополнение: Практика работы с системами контроля версий