Что такое svn репозиторий

KNZSOFT Разработка ПО, консультации, учебные материалы

Князев Алексей Александрович. Независимый программист и консультант.

SVN и Git для начинающих. Практика использования

Материал страницы находится в разработке!

Введение

Данное руководство написано для практического ознакомления с популярной сегодня системой контроля версий Subversion, также известной как SVN. Пользователи Linux смогут повторить все описанные в статье эксперименты на своём компьютере. Пользователи других операционных систем должны будут внести некоторые поправки.

Одной из отличительных черт данного руководства является проведение сравнений и аналогий между SVN и Git. Git был разработан несколько позже SVN, и был ориентирован на очень специфический проект — разработка ядра Linux, которая ведется очень большим кругом разработчиков разбросанных по всему миру. Архитектура и реализация Git оказалась привлекательной для ведения других программных проектов и сегодня, наверное, именно SVN и Git являются самыми популярными системами контроля версий. SVN и Git сильно отличаются по своим базовым идеям, и выбор между использованием SVN или Git должен опираться на понимание этих различий. В рамках данного руководства, мы будем не только изучать SVN и Git, но и акцентировать внимание на отличительных особенностях этих систем, что, кроме прочего, должно усилить продуктивность изучения — знакомство с тем, что и как может быть сделано по-другому, упростит запоминание материала.

Последний раздел посвящён специальным возможностям системы Git по трансформациям между своим локальным репозиторием и центральным репозиторием SVN. Многим будет интересно знать, что с центральным репозиторием SVN можно работать средствами Git. Такая синхронизация разноархитектурных репозиториев, доступная благодаря возможностям Git, поможет вам увидеть преимущества и недостатки разных подходов.

Примечание Данное руководство написано в контексте использования операционной системы Linux. Для других операционных систем необходимо вносить соответствующие коррективы.

Историческая справка

Subversion

Subversion — система управления версиями в свободной лицензии. Известна под сокращенным именем SVN. Разработка Subversion началась в 2000 году по инициативе и финансовой поддержке компании CollabNet Inc.

Основной целью проекта Subversion считается замена устаревший, на тот момент системы контроля версий CVS (Concurrent Versions System). Новый проект должен был сохранить всю функциональность CVS и избавиться от ряда его недостатков.

Официальный выпуск Subversion — 2004 год.

Разработка Git началась в 2005 году, по инициативе разработчика Linux — Линуса Торвальдса.

Двумя важнейшими требованиями к разрабатываемой системе контроля версий были требования эффективности (по скорости и объему) для больших проектов в миллионы строк и поддержки нелинейной разработки (тысячи параллельных веток). Кроме того, Git изначально ориентировался на удаленную специфику разработки проектов.

Технические вопросы устройства

Две концепции, используемые для разделения файлов

Чтобы разделить файловое хранилище на множество пользователей можно использовать одну из двух известных схем разделения.

Обе системы, Subversion и Git, используют вторую схему разделения данных (Copy-Modify-Merge), но делают это немного по-разному.

Физическое представление репозитория

Subversion

SVN относится к типу централизованных систем, в отличии от Git и Mercurial, которые являются представителями класса распределенных систем. Централизованность означает работу схемы только при наличии централизованного хранилища данных.

Развертывание системы Subversion может опираться на две разные физические системы хранения данных репозитория. Исторически, первый вариант организации репозитория был основан на использовании СУБД Berkeley DB. Позже, была выполнена реализация на основе специального файлового хранилища данных (FSFS), поддерживаемое собственными программными библиотеками. Начиная с релиза 1.2 для новых хранилищ, по умолчанию, используется FSFS.

Реализацию на основе СУБД Berkley DB можно считать более капризной. Во-первых, ее настройка требует большего внимания администратора. Во-вторых, Berkley DB требовательна к выбору низлежащей файловой системы — она должна поддерживать блокировки.

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

Логическое представление репозитория

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

SVN vs Git. Здесь мы наблюдаем существенное различие в использовании, и, особенно,
администрировании систем SVN и Git. В Git, под каждый проект в любой директории
можно реализовать работу локального репозитория, чего, часто, для индивидуальной
работы, бывает достаточно. Централизованный репозиторий, при его необходимости,
так же организуется под каждый проект отдельно, позволяя для каждого проекта
построить свою политику прав доступа. Если быть более точным, то Git значительно
сосредоточен именно на средствах управления версиями и, при использовании
централизованных репозиториев, для тонкого разделения доступа к коду проекта
множества пользователей удобнее использовать дополнительные оберточные средства
администрирования Git. Cреди последних, известными являются gitolite и gitosys.

Различают понятия стержневых ревизий (peg revision) и оперативных ревизий (operative revision). Стержневая ревизия представляет собой номер ревизии предназначенный для уточнения файловых историй для оперативных ревизий по которым выполняются операции команд. Т.е. Команда может быть задана по диапазону оперативных ревизий в которых может быть коллизии файловых историй связанных с операциями копирования, перемещения и уничтожения файлов. Чтобы однозначно указать требуемую файловую историю необходимо указывать стержневую ревизию по правому краю диапазона оперативных ревизий, так как история файла однозначно отслеживается только в обратном направлении. При
отслеживании истории в прямом направлении можно столкнуться, например, с разветвлением, созданным при копировании файла. Работа пользователя с файлами проекта выполняется в рабочей копии репозитория, которая создается получением файлового снимка всего репозитория SVN или его части (через уточнение нужной поддиректории) с помощью операции svn checkout (по умолчанию будет передана последняя ревизия). Если пользователь хочет зафиксировать изменения в репозитории проекта, то он должен выполнить операцию svn commit. При каждой фиксации кода создается новая ревизия с большим номером.

Основная суть организации репозитория Git в том, что он хранит файлы в виде файлов, а в качестве имени файла в репозитории используется значение хэш-функции SHA1, вычисленной по содержимому файла.

Таким образом, одинаковые файлы имеют одинаковое значение хеш-функции и хранятся один раз.

Одной из особенностей такого файлового хранения является то, что в Git не хранятся директории как таковые, а только в виде файловых путей. Следовательно, пустую директорию нельзя сохранить в репозитории Git.

Логическое представление репозитория

Объекты репозитория Git бывают четырех типов — blob, tree, commit и tag.

Использование систем контроля версий

Получение справочной информации

Subversion (SVN)

Справочная информация по командам svn может быть получена обращением к самой утилите svn через команду svn help. Введя эту команду в консоли, вы получите полный список всех команд поддерживаемых текущей версией утилиты svn. Для получения информации по конкретной команде надо добавить ее после help. Например:

svn help checkout
svn help commit
svn help mkdir

Создание репозитория

Subversion (SVN)

Продумаем размещение и выберем имя для директории будущего репозитория SVN. При этом подумайте о правах доступа, если репозиторий будет разделяемый. Для простоты я
сделаю репозиторий в своем домашнем каталоге /home/knz с именем 0-svn-repository. Имя начинающееся с нуля предоставит дополнительный приоритет для данной директории для
многих типов сортировок при выводе списка директорий и такая директория не затеряется в окружении многих других директорий домашнего каталога.

Находясь в домашней директории выполним команду.

svnadmin create 0-svn-repository

Репозиторий создан. Пустой репозиторий имеет нулевой номер ревизии. Теперь в него можно добавлять проекты для управления. Дальнейшая последовательность действий может быть такая.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

SVN — Краткое руководство

Система контроля версий (VCS) — это программное обеспечение, которое помогает разработчикам программного обеспечения работать вместе и вести полную историю своей работы.

Ниже приведены цели системы контроля версий.

VCS делится на две категории.

Терминология контроля версий

Давайте начнем с обсуждения некоторых терминов, которые мы будем использовать в этом руководстве.

Репозиторий: Репозиторий является сердцем любой системы контроля версий. Это центральное место, где разработчики хранят всю свою работу. Репозиторий хранит не только файлы, но и историю. Доступ к репозиторию осуществляется через сеть, выступая в роли сервера и инструмента контроля версий, выступающего в роли клиента. Клиенты могут подключаться к хранилищу, а затем они могут сохранять / извлекать свои изменения в / из хранилища. Сохраняя изменения, клиент делает эти изменения доступными для других людей, а путем извлечения изменений клиент воспринимает изменения других людей как рабочую копию.

Магистраль: Магистраль — это каталог, в котором происходит вся основная разработка, и обычно проверяется разработчиками для работы над проектом.

Теги : каталог тегов используется для хранения именованных снимков проекта. Работа с тегами позволяет задавать описательные и запоминающиеся имена конкретной версии в репозитории.

Например, LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT более запоминающимся, чем

UUID репозитория: 7ceef8cb-3799-40dd-a067-c216ec2e5247 и

Ветви: Операция ветвления используется для создания другой линии развития. Это полезно, когда вы хотите, чтобы процесс разработки проходил в двух разных направлениях. Например, когда вы выпускаете версию 5.0, вы можете захотеть создать ветку, чтобы разработка функций 6.0 могла быть отделена от исправлений ошибок 5.0.

Рабочая копия: Рабочая копия — это снимок хранилища. Репозиторий является общим для всех команд, но люди не изменяют его напрямую. Вместо этого каждый разработчик проверяет рабочую копию. Рабочая копия — это личное рабочее место, где разработчики могут выполнять свою работу, оставаясь изолированными от остальной части команды.

Фиксация изменений. Фиксация — это процесс сохранения изменений с частного рабочего места на центральный сервер. После фиксации изменения становятся доступными для всей команды. Другие разработчики могут получить эти изменения, обновив свою рабочую копию. Фиксация — это атомарная операция. Либо весь коммит успешен, либо откатан. Пользователи никогда не видят наполовину завершенный коммит.

Репозиторий: Репозиторий является сердцем любой системы контроля версий. Это центральное место, где разработчики хранят всю свою работу. Репозиторий хранит не только файлы, но и историю. Доступ к репозиторию осуществляется через сеть, выступая в роли сервера и инструмента контроля версий, выступающего в роли клиента. Клиенты могут подключаться к хранилищу, а затем они могут сохранять / извлекать свои изменения в / из хранилища. Сохраняя изменения, клиент делает эти изменения доступными для других людей, а путем извлечения изменений клиент воспринимает изменения других людей как рабочую копию.

Магистраль: Магистраль — это каталог, в котором происходит вся основная разработка, и обычно проверяется разработчиками для работы над проектом.

Теги : каталог тегов используется для хранения именованных снимков проекта. Работа с тегами позволяет задавать описательные и запоминающиеся имена конкретной версии в репозитории.

Например, LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT более запоминающимся, чем

UUID репозитория: 7ceef8cb-3799-40dd-a067-c216ec2e5247 и

Ветви: Операция ветвления используется для создания другой линии развития. Это полезно, когда вы хотите, чтобы процесс разработки проходил в двух разных направлениях. Например, когда вы выпускаете версию 5.0, вы можете захотеть создать ветку, чтобы разработка функций 6.0 могла быть отделена от исправлений ошибок 5.0.

Рабочая копия: Рабочая копия — это снимок хранилища. Репозиторий является общим для всех команд, но люди не изменяют его напрямую. Вместо этого каждый разработчик проверяет рабочую копию. Рабочая копия — это личное рабочее место, где разработчики могут выполнять свою работу, оставаясь изолированными от остальной части команды.

Фиксация изменений. Фиксация — это процесс сохранения изменений с частного рабочего места на центральный сервер. После фиксации изменения становятся доступными для всей команды. Другие разработчики могут получить эти изменения, обновив свою рабочую копию. Фиксация — это атомарная операция. Либо весь коммит успешен, либо откатан. Пользователи никогда не видят наполовину завершенный коммит.

Настройка среды SVN

Установка SVN

Subversion — это популярный инструмент контроля версий с открытым исходным кодом. Это с открытым исходным кодом и доступно бесплатно через Интернет. Он поставляется по умолчанию с большинством дистрибутивов GNU / Linux, поэтому он может быть уже установлен в вашей системе. Чтобы проверить, установлен он или нет, используйте следующую команду.

Если клиент Subversion не установлен, команда сообщит об ошибке, в противном случае будет отображена версия установленного программного обеспечения.

Настройка Apache

Мы видели, как установить клиент Subversion в GNU / Linux. Давайте посмотрим, как создать новый репозиторий и разрешить доступ пользователям.

Пакет mod_dav_svn позволяет получить доступ к хранилищу по HTTP, через сервер Apache httpd, а пакет subversion устанавливает инструмент svnadmin.

Настройка пользователя

Давайте создадим пользователя Джерри

Создайте родительский каталог Subversion для хранения всей работы (см. /Etc/httpd/conf.d/subversion.conf ).

Настройка репозитория

Давайте изменим пользователя и группу владельцев хранилища.

Проверьте, включен ли SELinux или нет с помощью инструмента состояния SELinux.

Для нашего сервера SELinux включен, поэтому мы должны изменить контекст безопасности SELinux.

Чтобы разрешить фиксацию по HTTP, выполните следующую команду.

Перезапустите сервер Apache, и мы закончили с настройкой сервера Apache.

Традиционно, у каждого проекта Subversion есть каталоги стволов, тегов и веток непосредственно в корневом каталоге проекта.

Магистраль — это каталог, в котором происходит вся основная разработка, и обычно проверяется разработчиками для работы над проектом.

Каталог тегов используется для хранения именованных снимков проекта. При создании производственного выпуска команда помечает код, который входит в выпуск.

Каталог веток используется, когда вы хотите заниматься разными направлениями развития.

Давайте создадим структуру каталогов стволов, тегов и ветвей в репозитории проекта.

Теперь импортируйте каталоги из / tmp / svn-template в репозиторий.

Жизненный цикл SVN

Жизненный цикл системы контроля версий обсуждается в этой главе. В последующих главах мы увидим команду Subversion для каждой операции.

Создать репозиторий:

Хранилище является центральным местом, где разработчики хранят всю свою работу. Хранилище хранит не только файлы, но и историю изменений. Это означает, что он поддерживает историю изменений, внесенных в файлы.

Операция ‘create’ используется для создания нового хранилища. В большинстве случаев эта операция выполняется только один раз. Когда вы создаете новый репозиторий, ваша VCS будет ожидать, что вы скажете что-то для его идентификации, например, где вы хотите, чтобы он был создан, или какое имя должно быть присвоено репозиторию.

Проверять, выписываться

Операция «Оформить заказ» используется для создания рабочей копии из хранилища. Рабочая копия — это личное рабочее место, где разработчики вносят свои изменения, а затем отправляют эти изменения в хранилище.

Обновить

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

Предположим, Том и Джерри — два разработчика, работающие над проектом. Оба проверяют последнюю версию из репозитория и начинают работать. На данный момент их рабочие копии полностью синхронизированы с хранилищем. Джерри завершает свою работу очень эффективно и вносит свои изменения в хранилище.

Выполнить изменения

После оформления заказа можно выполнять различные операции для внесения изменений. Редактировать это самая распространенная операция. Можно редактировать существующий файл, чтобы добавить / удалить содержимое из файла.

Можно добавлять файлы / каталоги. Но сразу же эти файлы / каталоги не становятся частью репозитория, вместо этого они добавляются в ожидающий список изменений и становятся частью репозитория после операции фиксации.

Точно так же можно удалить файлы / каталоги. Операция удаления немедленно удаляет файл из рабочей копии, но фактическое удаление файла добавляется в ожидающий список изменений, и изменения вносятся в репозиторий после операции фиксации.

Операция «Переименовать» изменяет имя файла / каталога. Операция «Перемещение» используется для перемещения файлов / каталогов из одного места в другое в дереве хранилища.

Обзор изменений

Когда вы извлекаете рабочую копию или обновляете рабочую копию, ваша рабочая копия полностью синхронизируется с хранилищем. Но когда вы вносите изменения в свою рабочую копию, она становится новее, чем хранилище. Хорошей практикой является проверка ваших изменений перед операцией ‘commit’.

Операция «Состояние» перечисляет изменения, которые были внесены в рабочую копию. Как мы уже упоминали ранее, каждый раз, когда вы вносите изменения в рабочую копию, все эти изменения становятся частью ожидающего изменения списка. И операция «статус» используется, чтобы увидеть ожидающий список изменений.

Операция «Статус» предоставляет только список изменений, но не подробную информацию о них. Можно использовать операцию diff для просмотра деталей изменений, которые были внесены в рабочую копию.

Исправить ошибки

Давайте предположим, что кто-то внес изменения в свою рабочую копию, но теперь он хочет отбросить эти изменения. В этой ситуации поможет операция «возврат».

Источник

Установка и настройка SVN (сервер+клиент)

По просьбам трудящихся, а так же учитывая, что есть статья по установке SVN (правда +Trac) под Linux, решил написать краткое описание установки и настройки SVN для Windows.
Ничего нового для людей, хорошо знающих и работающих с SVN, здесь не будет. Цель статьи — помочь некоторому проценту новичков, пребывающих на Хабре, таки осилить изучение этой системы контроля версий.

С самого начала сообщаю, что для SVN есть подробное руководство. Называется оно svn-book и доступно на сайте и идет вместе с CollabNet Subversion-server. Так же про установку и настройку svnserv с Apache есть описание в учебнике по TortioseSVN (довольно хорошая подробная помощь на русском).

На самом деле SVN-клиент может отлично работать и без сервера. Репозиторий (хранилище кода) можно создать в любом каталоге на собственном HDD, или в сетевом каталоге. Сервер требуется лишь для удаленного доступа к репозиторию, не больше. Локальный репозиторий годится, если над проектом работает один человек и ему просто нужна система контроля версий своего приложения и бэкапы.

Если работа ведется в команде или требуется удаленный доступ к репозиторию (через Интернет, например), нужно устанавливать SVN-сервер. Он может работать самостоятельно, либо через веб-сервер Apache. В первом случае доступ к репозиториям будет по протоколу svn://, во втором — http(s)://. Доступ через веб-сервер нужен при проблемах с файрволом, когда он пропускает только HTTP-трафик, а так же для работы некоторых утилит-примочек к SVN-серверу.

Установка сервера

Самую свежую версию svn-cервера всегда можно найти на сайте subversion.tigris.org. Чистый svn-сервер без Apache в комплекте, и без визуальных примочек доступен только для версии 1.4.6, в то время как текущая версия 1.5.0. Для версии 1.5.0 есть выбор между CollabNet Subversion-server-1.5.0 (

5 MB). Первый идет в комплекте с Apache, второй — с Apache и плагином для Windows Management Console. Так же для VisualSVN есть платная возможность интеграции с Visual Studio.

A. Установка и настройка сервера VisualSVN (svn-сервер + Apache + консоль управления) самая простая. Эту версию нельзя установить без Apache.

1) Скачиваем файл VisualSVN-Server-1.5.1.msi или новее. Запускаем установку.
2) В мастере установки указываем, использовать ли для доступа HTTPS, либо просто HTTP. Указываем порт для прослушивания по выбранному протоколу и способ аутентификации. Так же указываем каталог, в котором будут храниться репозитории.
3) После установки открываем Management Console (через Пуск, например) и создаем пользователей и репозитории.

Теперь ваши репозитории доступны через выбранный протокол (HTTP или HTTPS) по указанному при установке хосту: порту (например, localhost:8443/svn/). Их можно просматривать как из браузера (через xsl), так и из SVN-клиета.

Работа с сервером VisualSVNбезусловно самая простая.

B. Установка CollabNet Subversion Server (svn-сервер + Apache опционально).

1) Скачиваем файл CollabNetSubversion-server-1.5.0-23.win32.exe или версию новее. Запускаем его на установку.
2) Шаг Choose Components. Устанавливаем флажок SVNSERVE в любом случае. Если требуется установить так же Apache для SVN, устанавливаем флажок напротив него.
3) На шаге sunserve Configuration устанавливаем порт для sunserve (по умолчанию 3690, менять его смысла нет, если он не занят) и путь к репозиториям (каталог, где вы будете создавать отдельные репозитории в виде подкаталогов).
4) Затем настраивается Apache: хост/порт, путь к репозиториям (тот же, что и для svnserve) и префикс для URL (http://host:port/prefix). Префикс нужен на случай, если Apache будет использоваться не только для обслуживания SVN.

После установки появятся две новых службы Windows: Subversion Server (наш svnserv.exe) и Apache2.2 (если он был включен при установке). Чтобы все заработало их нужно запустить.

С. Установка svnserve 1.4.6 (чистый svn-сервер).

Именно эту работу (если не считать установку Apache) сделал за вас установщик CollabNet Subversion Server. В случае установки svnserve 1.4.6 доступ к репозиторию будет только по протоколу svn://.

D. Создание репозитория. Выделяю этот пункт отдельным разделом. Если в VisualSVN создание репозитория производится кликом мыши, то для svnserve (в том числе в версии от CollabNet) репозиторий создается из консоли. В поставке snv-сервера есть файл snv-install-folder\bin\svnadmin.exe. Если путь к snv-install-folder\bin еще не прописан в PATH, сделайте это.

Чтобы создать репозиторий, откройте консоль (cmd) и перейдите в каталог для хранения репозиториев, который вы указывали при установке (CollabNet) или создании сервиса (svnserve 1.4.6). Создайте новый пустой подкаталог (например, example-repository). В консоли выполните команду: svnadmin create example-repository. В только что созданном каталоге появится структура файлов svn. В них есть много полезных «штук», о которых можно почитать в svn-book и учебнике.

В подкаталоге conf можно настроить основные параметры репозитория. Прежде всего требуется закрыть доступ в репозиторий кому-попало. В файле svnserve.conf раскомментируем строки
# anon-access = read
# auth-access = write
Не забудьте убрать так же пробел после #, т.к. иначе будет ошибка чтения конфига. anon-access определяет доступ анонимным пользователям, auth-access — зарегистрированным. Они могут принимать значения «write», «read» и «none». Обычно anon-access = none и auth-access = write.

Далее надо раскомментировать # password-db = passwd, а в файл passwd в этом же каталоге добавить строку user = password.

Для начала такое определение доступа годится, но в последствии конечно пароли надо шифровать (читаем svn-book).

На этом установка сервера закончена и можно установить клиент.

Установка клиента.

Некоторые профессионалы предпочитают работать с консолью. Наверное это не самый удобный способ, особенно для новичков, поэтому рассматривать его не будем. Другие работают с SVN через плагины к своим IDE. Это самый лучший способ, но поскольку разных IDE много и плагинов к ним тоже, в этой статье работу с ними не описываем.

Самым популярным и признанным клиентом SVN под Windows является TortoiseSVN. После его установки вы не получите отдельной программы, которую можно «классически запустить», клиент встраивается в проводник Windows, а команды для него доступны из контекстного меню файла (в т.ч. и в Total Commander).

Описывать установку клиента нет никакого смысла, там все элементарно просто.

О том, как работать с TortoiseSVN, подробно расписано в руководстве TortoiseSVN Клиент Subversion для Windows.

Дублировать это подробное руководство, конечно, желания нет, но все же super-fast-start work with tsvn опишу.

1) Для просмотра любого репозитория после установки TortoiseSVN вызовите контекствное меню на любом файле в системе, выберите меню TortoiseSVN→Repo-browser. В открывшемся окошке введите адрес репозитория с протоколом (например, localhost:8443/svn/test или svn://someserver:3690/proj1/trunc). Откроется окно просмотра репозитория (с помощью кнопки напротив строки адреса можно выбрать, какую ревизию просмотреть; HEAD — это последняя ревизия).

2) Для создания локального репозитория (не используя сервер) запускается пункт меню TortoiseSVN→Create repository here. на нужном каталоге. В Repo-browser такой репозиторий доступен по протоколу file:///.

3) Для скачки себе версии из существующего репозитория запускается пункт меню TortoiseSVN→SVN Checkout на каталоге, в который сольется версия.

4) Если вы еще не использовали SVN и хотите залить на сервер свою текущую версию исходников, запустите пункт меню TortoiseSVN→Import. на каталоге, в котором лежит версия (при этом не забудьте, что разрабатываемую ветку надо лить в trunk).

5) TortoiseSVN→Export. используется для получения чистой версии исходников из репозитория (без служебных файлов контроля версий).

6) Если контекстное меню вызвать на каталоге, который является локальной (рабочей) копией репозитория, контекстное меню значительно расшириться. Например, появятся пункты Update (слить последние изменения с сервера) и Commit (закачать ваши изменения на сервер).

На последок рекомендую почитать интересную серию статей Работа с Tortoise SVN.

Источник