Программа для работы: http://tortoisesvn.net/

svn checkout http://repository.url/svn/name — извлекаем файлы проекта из репозитория, сокращение: svn co;

svn update — получаем обновления из репозитория, сокращение: svn up;

svn update -r rev_num ./file_name — извлекаем ревизию файла с номером rev_num;

svn add ./file_name — добавляем файл в репозиторий (не важно текстовый или бинарный);

svn commit ./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 http://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 http://repository.url/svn/name/trunk/ http://repository.url/svn/name/branches/new_branch_name/ — создаем ветку с названием new_branch_name из главной линии разработки;

svn merge --dry-run -r rev_num1:rev_num2 http://repository.url/svn/name/trunk/ — проверяем, что будет изменено при объединении веток, где rev_num1 — номер ревизии, когда ваша ветка была «открыта», или это м.б. номер предыдущего объединения (слияния), rev_num2 — версия главной линии разработки, с которой производим объединение. Необходимо отметить, что все изменения будут применены для директории, в которой выполнялась эта команда;

svn merge -r rev_num1:rev_num2 http://repository.url/svn/name/trunk/ — синхронизирует вашу ветку с главной линией разработки с учетом ревизий: rev_num1 — номер ревизии, когда ваша ветка была «открыта», или это м.б. номер предыдущего объединения (слияния), rev_num2 — версия главной линии разработки, с которой производим объединение. Необходимо отметить, что все изменения будут применены для директории, в которой выполнялась эта команда;

Стратегии использования Subversion

Цель написания данного документа — рассмотреть несколько возможный стратегий применения svn при создании репозитория web-проекта. Репозиторий должен удовлетворять основному требованию — в стабильную версию проекта не должны попадать дестабилизирующие изменения. Вариант, когда репозиторий испольуется просто как хранилище файлов, не рассматриваем из-за его явной простоты. Более того, он не соответствует основному требованию, предъявляемому к репозиторию.

Стартегия 1

Данная стратегия является упрощенной и может быть применена в небольших коллективах разработчиков. Однако, предпочтительнее использовать стратегию 2, по скольку она в полной мере удовлетворяет требованию, что в стабильную версию проекта не должны попадать дестабилизирующие изменения. SVN позволит легко перейти от использования одной стратегии к другой, необходимо будет лишь утвердить ряд новых требований, предъявляемых к внесению изменений в репозиторий.

Структура репозитория

/
    /trunk
    /tags/
        /0.0.1
        /0.0.2
        ...
    /branches/
        /0.0.1
        /0.0.2
        ...

Директория /trunk — основная ветка разработки проекта. В нее вносятся все изменения и исправления ошибок.
Директория /tags содержит релизы проекта. Именно из поддиректорий директории /tags исходный код выкладывается на рабочие сервера. 
Директория /branches необходима для упрощения внесения больших изменений в код проекта. В ней хранятся ветви разработки. Если человек разрабатывает большую фичу, то он должен создать себе бранч и время от времени синхронизировать его с trunk. По окончании разработки фичи этот бранч сливается с транком и удаляется.

Итак, /trunk — основная ветвь разработки системы. Релизы создаются на основе содержимого директории /trunk. Создавать релизы на основе бранчей в данном случае не рекомендуется.

Соглашение о релизах и ветвях разработки

Номер релиза состоит из трех цифр, разделенных точкой. Для удобства описания обозначим его как X.Y.Z.

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

Цифра Y отвечает за добавление новых фич и исправление ошибок, то есть номер Y увеличиваем при добавлении новых возможностей, заметных на уровне конечного пользователя. Поясню на счет исправления ошибок — на первый взгляд может показаться, что за исправление ошибок должен отвечать номер Z, но это не так. Например, в релизе 1.2.3 исправили несколько ошибок, залили их в /trunk. А через некоторое время выпустили новую версию 1.3.0 с фичами и этими исправлениями ошибок, т.е. багфиксы «автоматом» слились в Y при создании нового релиза из /trunk.

Z — исправление ошибок, внесение незначительных исправлений (например, небольшие изменения дизайна).

Примеры

Пример 1
Текущий релиз: 1.2.4.
Задание: Необходимо исправить ряд небольших ошибок, замеченных с момента релиза.
Действия: Вносим изменения в /trunk. Создаем стабилизирующий релиз /tags/1.2.5/. Выкладываем.

Пример 2
Текущий релиз: 1.2.4
Задание: Необходимо разработать дополнительную фичу, выполнение задания займет от нескольких дней до нескольких недель.
Действия: Создаем бранч /branches/1.3.0/. Работаем в бранче. Несколько раз в неделю синхронизируемся с /trunk для поддержания актуальности бранча и упрощения последующего слияния бранча с транком. По окончании разработки бранч синхронизируется с транк. Тестируется. Если все в порядке, то изменения заливаются в транк. Бранч удаляется. На основе транка делается релиз /tags/1.3.0/.

Пример 3
Текущий релиз: 1.2.4
Задание: Необходимо разработать несколько (пусть две) дополнительных фич, выполнение задания займет от нескольких дней до нескольких недель.
Действия: Создаем бранчи /branches/1.3.0 и /branches/1.3.1. Работаем независимо в разных бранчах. Несколько раз в неделю бранчи синхронизируются с trunk для поддержания актуальности бранчей и упрощения последующего слияния бранчей с транком. По окончании разработки бранчи по очереди синхронизируется с транком. Результат тестируется. Если все в порядке, то изменения заливаются в /trunk. Бранчи удаляются. На основе транка делается релиз /tags/1.3.0/.

Стартегия 2

Это классическая стратегия, рекомендуемая в документации по svn. Применения этой стратегии будет гарантировать, что в репозиторий будет удовлетворять требованию, что в стабильную версию проекта не попадают дестабилизирующие изменения. Эта глава всего лишь свободный пересказ одной из глав руководства по svn.

Структура репозитория

/
    /trunk
    /tags/
        /0.1.0
        /0.1.1
        ...
    /branches/
        /0.1-stable
        /0.2.0
        /0.2.1
        ...

Директория /trunk — основная ветка разработки проекта. В нее вносятся все изменения и исправления ошибок.
Директория /tags содержит релизы проекта. Именно из поддиректорий директории /tags исходный код выкладывается на рабочие сервера.
Директория /branches необходима для упрощения внесения больших изменений в код проекта, а также для внесения исправлений в текущий релиз проекта.

Соглашения о релизах

Номер релиза состоит из трех цифр, разделенных точкой. Для удобства описания обозначим его как X.Y.Z.

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

Цифра Y отвечает за добавление новых фич и исправление ошибок, то есть номер Y увеличиваем при добавлении новых возможностей, заметных на уровне конечного пользователя. Поясню на счет исправления ошибок — на первый взгляд может показаться, что за исправление ошибок должен отвечать номер Z, но это не так. Например, в релизе 1.2.3 (на самом деле изменения вносятся в бранч /branches/1.2-stable) исправили несколько ошибок, залили их в /trunk. А через некоторое время выпустили новую версию 1.3.0 с фичами и этими исправлениями ошибок, т.е. багфиксы «автоматом» слились в Y при создании нового релиза из /trunk.

Z — исправление ошибок, внесение незначительных исправлений (например, небольшие изменения дизайна).

Соглашения о ветвях разработки

Ветви разработки могут быть двух типов в зависимости от назначения ветви.
Первый вариант — ветви для существенных изменений (номера вида 0.1.0, 0.2.0 и т.д.). Если человек разрабатывает большую фичу, то он должен создать себе бранч и время от времени синхронизировать его с /trunk. По окончании разработки фичи этот бранч сливается с /trunk и удаляется. Далее будем называть такие ветви временными.
Если ветвь временная, то ее название будет состоять из трех цифр — X.Y.Z. Номер Y должен быть на единицу больше номера текущего релиза. То есть если текущий релиз имеет версию 1.2.4, то создавать ветвь необходимо с номером 1.3.0.

Второй вариант — ветви, соответствующие релизам, выкладываемым на рабочие сервера (номера вида 0.1-stable, 0.2-stable). Эти ветви необходимы для исправления ошибок в текущем релизе. На основе этих ветвей создаются стабилизационные релизы. Это ветви релиза. Номера ветвей релиза имеют другую структуру — X.Y-stable.

Примеры

Пример 1
Исходные данные: исходники в /trunk.
Задание: Необходимо создать первый релиз и выложить код на рабочие сервера.
Действия: 
Создаем бранч для поддержки (см. пример 2) релиза (svn copy /trunk /branches/1.0-stable)
Создаем первый релиз (svn copy /branches/1.0-stable /tags/1.0.0)

Пример 2
Исходные данные: В релизе 1.0.0 из примера 1 обнаружен ошибка.
Задание: Необходимо исправить ошибку.
Действия: 
Исправляем ошибку в /branches/1.0-stable
Портируем изменения в /trunk
Создаем стабилизационный релиз /tags/1.0.1 (svn copy /branches/1.0-stable /tags/1.0.1)
Переключаем сервер на новый релиз командой svn switch.

Пример 3
Исходные данные: текущий релиз 1.0.1.
Задание: разработать новую фичу для проекта, вермя выполнения около недели.
Действия:
Создаем бранч /branches/1.2.0
Все изменения относительно новой фичи вносятся в эту ветвь.
Ветвь систематически синхронизируется с /trunk для поддержания актуальности ветви.
По окончании работ над фичей ветвь сливается с /trunk.
/trunk тестируется.
Если все в порядке, то бранч /branches/1.2.0 удаляется.
На основе /trunk создается новые релиз /tags/1.2.0
На основе /tags/1.2.0 создается бранч релиза /branches/1.2-stable
/tags/1.2.0 выкладывается на рабочие сервера

Замечания
/trunk — основная ветвь разработки системы.
Релизы создаются на основе ветвей /branches/x.x-stable.
Следует отметить, что при выходе релиза 1.2.0 отпадает необходимость в поддержке бранча /branches/0.1-stable. Эту ветвь можно удалить.

Выводы

Вторая стратегия более надежна, но ее использование влечет за собой необходимость всегда деражть под рукой две рабочии копии проекта — бранч релиза и транк. Также потребуются некоторые усилия по поддержанию этих версий синхронизированными (в плане исправления ошибок). Первая стратегия более простая, не требует особых навыков управления репозиторием, и, пожалуй, больше подходит на начальном этапе использования svn или для небольших команд разработки.

Полную документацию по subversion на русском языке можно посмотреть по ссылке Управление версиями в subversion.
Если вы нашли ошибку на этой странице, сообщите о ней, пожалуйста, по адресу gnuman@yandex.ru.
Спасибо!