Svn repository что это
Subversion
Введение
Subversion (сокращенно SVN) — система управления версиями (Version Control System, VCS). Обычно тулзы этого рода считаются теми, кто с ними не знаком, чем-то нужным только большим командам программистов. Но на самом деле, они крайне полезны даже одиночке, и даже не программисту — всем, кому приходится редактировать какие-либо файлы. Так, я встречал весьма восторженное описание системы CVS (идейный предшественник SVN и первая свободная VCS — благодаря чему она до сих пор достаточно распространена) от какого-то то ли журналиста, то ли писателя, ее использовавшего.
Почему SVN?
Что такое SVN?
Subversion — централизованная система управления версиями — то есть, она хранит файлы и их историю в центральном хранилище, называемом репозиторий. Subversion ориентирована на работу с файлами — она следит за изменениями файлов, отданных под ее контроль, и сохраняет их. Также, в отличие от CVS, SVN следит и за папками. Подробней об отличиях (и вообще о системе) можно почитать тут, раздел «Subversion и CVS».
Основные понятия
И как с этим работать?
Также стоит учитывать, что однажды залитое в репозиторий останется там навсегда — даже если удалить следующей ревизией, оно останется в той ревизии, в которой попало. Поэтому постарайтесь не заливать случайно файл с паролями или просто ненужный здоровый файл, который навсегда раздует репозиторий своим весом.
Точнее, один метод есть — нужно сдампить репозиторий, профильтровать дамп, удалив из него вредный файл, грохнуть старый репозиторий и создать новый, залив в него профильтрованный дамп. Но это не только сложно, но и требует административного доступа к репозиторию (а точнее — к папке с ним).
Разрешение конфликтов
Если над проектом работает более одного человека — будут неизбежно возникать конфликты. Допустим, есть два пользователя — Гарри и Салли (да, я сперва заглянул в SVN Book, но картинки оттуда тянуть лень). Они работают с одним и тем же файлом А.
Экспорт
Ветви
SVN поддерживает идеологию ветвей — когда независимо от основной линии развития проекта разрабатываются побочные, при этом изменения могут копироваться между ветвями. Правда, поклонники Git утверждают, что поддержка ветвей в SVN говно и недостойна таковой называться. Возможно и правы, Git и правда выглядит очень любопытно и обеспечивает контроль над туевой хучей ветвей ядра Linux (для которого и был создан Торвальдсом).
С ветвями я не работал, поэтому рекомендую почитать на эту тему SVN Book.
Создание репозитория
Чтобы работать с репозиторием, нужен, как ни странно, сам репозиторий. Хорошо, когда подключаешься к существующему проекту — он уже есть. А если проект начинаешь сам? Тогда его необходимо создать. И тут есть два варианта — локальный и удаленный репозитории.
Создание локального репозитория
Прежде всего — надо создать папку под репозиторий. Затем — создать в ней репозиторий командой create (точнее, в случае официального клиента — svnsdmin create). При этом нужно выбрать тип репозиторий — FSFS или BDB. Не буду вдаваться в подробности, но лучше создать FSFS (а свежие версии так и делают по дефолту). Кроме того, BDB репозиторий нельзя создавать на нелокальной файловой системе (например, на подмонтированном сетевом ресурсе) — через некоторое время он просто сломается.
URL для созданного локально репозитория — file:///path/to/repository, например, если репозиторий в папке C:\MyRepository, то его URL — file:///C:/MyRepository.
С локальным репозиторием клиент SVN работает непосредственно — сервер не требуется. Для обслуживания репозитория (как локального, так и выведенного в сеть сервером) предназначена утилита svnadmin.
Свежесозданный репозиторий пуст, имеет нулевую ревизию и непригоден для работы. В него необходимо импортировать начальную версию. Для этого надо создать папку с некоторым начальным содержимым и импортировать ее командой import. После этого можно извлекать рабочую копию и работать с ней, а импортированную папку удалить.
Немного о содержимом этой папки. Вообще, хранить файлы в репозитории можно как угодно, но есть рекомендованный стандарт. Согласно ему в репозитории при импорте создаются пустые папки trunk, branches и tags. Если планируется хранить в репозитории несколько проектов — то для каждого создается папка, а уже в этих папках — папки trunk, branches и tags.
Удаленный репозиторий
Удаленный репозиторий может быть в локальной сети и в интернете.
В первом случае (а также во втором, когда репозиторий на своем хостинге) на хосте репозитория следует поднять и настроить SVN сервер — родной svnserve (говорят, крайне дыряв) или на основе apache+webdav или иной SVN-плагин. Но это тема не этой статьи, да и не знаком я с ней.
Но есть еще один вариант — это SVN-хостинги. Их немало, как платных, так и бесплатных. Они предоставляют уже готовый репозиторий, а если и нет — то сами расскажут, как его создать. Лично я пользуюсь хостингом от гугла. Остальных — доставит он же 🙂
Репозиторий в интернете позволяет синхронизировать свои рабочие копии на разных компах, а также работать над проектом вместе с другими людьми, возможно на другом конце мира. А также, при желании — предоставлять всем желающим доступ (на чтение) к самой свежей версии исходников.
Круто. А где взять?
На официальном сайте, теперь под крылышком у Apache. Однако, официальный клиент — это кроссплатформенная консольная программа. Не всем они нравятся, хотя свои плюсы у них есть. Поэтому существуют альтернативные клиенты и оболочки на официальный консольный клиент.
Лично мне нравится TortoiseSVN — это GUI-клиент (т.е. в отличие от оболочки он выполняет действия сам, а не передает их консольной программе svn), выполненный как расширение Проводника Windows. Вся работа с ним производится через контекстное меню Проводника. Также совместимо с Total Commander и ему подобными файл-менеджерами (теми, которые запрашивают иконки файлов у винды и умеют показывать контекстное меню Проводника). Поклонникам FAR’а и других операционок могу порекомендовать только гугл. Также TortoiseSVN показывает состояние файлов, накладывая оверлеи на их иконки. Благодаря этому с первого взгляда видно состояние рабочей копии — модифицированные файлы, конфликты и так далее.
Стоит также обратить внимание на то, что TortoiseSVN добавляет свои пункты в контекстное меню, показываемое при перетаскивании файлов/папок правой кнопкой мыши. Там такие полезные команды, как Export, Copy, Move.
Алсо, в разделе языковых пакетов к TortoiseSVN имеется годный мануал в PDF, на русском. Рекомендую почитать, это своеобразный аналог SVN Book для TortoiseSVN.
Настройки TortoiseSVN
Настройки вызываются через контекстное меню проводника, вызванное на любом объекте, пункт TortoiseSVN->Settings. Их там довольно много, опишу основные.
Здесь следует настроить Global ignore pattern — список масок файлов, которые SVN будет игнорировать — т.е. не предлагать их добавить, зафиксировать и т.д. Сюда следует внести различные временные файлы — на скриншоте, например, внесены файлы, создаваемые Delphi версий по 7-ю. Здесь же можно поменять язык, русский поддерживается — но не гарантирую совпадение терминологии, т.к. пользуюсь английской версией.
Здесь внимания заслуживает Status cache. Выбранный вариант обеспечивает рекурсивную проверку статуса — папка будет помечена как модифицированная даже если модифицированный файл в одной из ее подпапок.
При снятой галочке «Show overlays and context menu only in explorer» можно использовать TSVN из менеджеров вроде Total Commander.
Галочки Show overlay for позволяют отключить назойливые метки на файлах, не находящихся под присмотром SVN.
Галочки в поле Drive Types позволяют отвадить SVN от проверки на модификации медленные носители и флешки (последнее — чтобы оно не мешало их извлекать), а также от заданных дисков.
На вкладке Network можно настроить доступ к сети и выбрать клиент для SSH, но у меня там значения по умолчанию (разве что, ЕМНИП, я вручную указал использовать прилагающийся к TortoiseSVN TortoisePLink.exe как клиент SSH).
На вкладке Saved data можно почистить истории и сохраненные данные аутентификации.
На вкладке Hook scripts можно добавить программы, срабатывающие при определенных событиях. У меня там, например, внесен скрипт, срабатывающий после обновления одной из РК.
На остальных вкладках (кроме рассмотренных далее) преимущественно настройки вида и поведения. Можно настроить их на свой вкус или удовлетвориться дефолтными.
Свистелки и перделки
На TortoiseSVN можно навешать некоторое количество дополнений, расширяющих возможности. Итак, по порядку.
Внешние Diff/Merge
Хотя к TortoiseSVN прилагается родная программа TortoiseMerge, мне больше нравятся WinMerge для сравнения файлов (он подсвечивает изменения внутри строк, позволяет редактировать файл прямо в нем и умеет подсвечивать синтаксис для многих языков, но не умеет сравнивать три файла) и KDiff3 (удобная программа для сравнения и слияния трех файлов, изначально созданная под KDE). Кроме них интерес могут представлять Beyond Compare, Structured Difference Viewer, утилиты Diff/Merge из состава Perforce и Borland StarTeam (или как его там, не помню уже) — но из них бесплатны только две последние.
Настраиваются эти утилиты в разделе External Programs, в прилагаемом хелпе есть командные строки для многих распространенных программ. В моем случае это
для обоих вариантов на вкладке Diff и
для вкладки Merge.
Интеграция с багтрекерами
Осуществляется плагинами, список их можно найти на сайте TortoiseSVN. После установки плагина его можно подключить к соответствующей РК на вкладке Hook Scripts->Issue Tracker Integration.
CommitMonitor
Пара глазок, которые сидят в трее и периодически проверяют указанные репозитории на наличие обновлений. Иногда полезно. Обитает вместе с другими полезняшками в разделе Other Tools сайта TortoiseSVN.
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
Репозиторий создан. Пустой репозиторий имеет нулевой номер ревизии. Теперь в него можно добавлять проекты для управления. Дальнейшая последовательность действий может быть такая.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Системы управления версиями файлов. Зачем они нужны?
Каждый программный/программно-аппаратный проект проходит в своей жизни несколько последовательных стадий: постановка задачи, поиск вариантов решения, написание кода и его отладка, поддержка проекта.
При этом многие разработчики и даже команды разработчиков вручную фиксируют историю изменений проекта (при его разработке и поддержке), осуществляют формирование готовых релизов (временных слепков состояния проекта), ветвление проекта (если нужна его адаптация под конкретные условия ТЗ или нужно проверить пару идей).
Естественно, такая работа с изменяющейся информацией чревата большой путаницей и частыми ошибками. Для автоматизации этой работы и были разработаны системы управления версиями файлов. Существует достаточно большое количество систем управления версиями файлов: CVS, SVN, Bazzar, Git и т. д. Выбор той или иной системы определяется личными предпочтениями разработчика и его требованиями. Но с точки зрения пользователя все эти системы похожи и решают одну задачу: контроль и управление версиями файлов.
Для того чтобы погрузиться в азы систем управления версиями файлов, ответим на простой, но в то же время важный вопрос: зачем они нужны? Этот вопрос является философским, особенно для разработчиков, полагающихся на свою память и предубеждение, что они никогда не ошибаются и лучше, чем машина, знают, что и где хранить. У таких разработчиков на жестком диске в разделе проектов часто можно найти папки, похожие на следующие:
Но при развитии проекта неплохо делать ревизии проекта (сохранять состояние всего проекта), и тогда у таких разработчиков появляется что-то вроде вот этого:
01022008 01022007 01042007
Причем, так как файлов много, то проекты начинают архивировать, и в таких папках лежат архивы. Автор прекрасно разбирается, что лежит в каждой из папок и зачем они нужны, естественно, полагая, что он всегда будет это помнить. Так происходит в краткосрочной перспективе, пока проект только один и автор в одиночестве работает с ним постоянно без перерывов.
Но как только автор вынужден оторваться от проекта или проектов становится несколько, то память начинает сдавать. Автор забывает, какая папка к чему относится и каково состояние проекта в конкретной папке.
При откате назад по ревизии автору нужно сначала выяснить, какую же ревизию использовать (вряд ли он делал полное описание всех изменений ревизии), для этого надо пройтись вручную по ревизиям и найти требуемую. Если же нужно сравнить ревизии, например, для выяснения, почему перестал работать проект, то надо вручную взять эти ревизии и искать, чем они отличаются.
Ситуация усугубляется, когда автор начинает заимствовать исходные коды одного проекта в другом. Надо помнить, откуда был взят файл, и если в нем будет найдена ошибка, то методом ручного копирования его нужно будет обновить в изначальном проекте.
Но вот автор заболел, уволился или просто не хочет больше работать над этим проектом, и нужно передать проект другому разработчику. Что в этом случае делает автор? Обычно люди такого типа говорят: «Вот тебе все исходные коды, разберешься» — и отдают ворох ревизий проекта, чаще всего без сопроводительной документации и разработчику, который не в курсе темы.
Поставьте себя на место того разработчика, которому поручили вести проект, и этот проект нужно было сдать вчера. В результате банальное наращивание функциональности проекта или поиск неисправностей и нерабочих участков проекта превращается в сплошную головную боль. Но разработчика-автора это мало волнует, он свой проект отдал и это его не касается.
Чем помогают системы контроля версий в данном случае? Как следует из названия, они берут на себя работу по управлению версиями и ревизиями исходных файлов проекта, то есть:
Все это возможно благодаря тому, что эти системы автоматически (то есть без ошибок) ведут историю изменений файла. Эта история, в пределах одного репозитория, может развиваться только в одном направлении. Проще говоря, репозиторий никогда ничего не забывает. Единственное, что требуется от пользователя, это аккуратно заполнять комментарии к изменениям версий файлов для быстрой навигации по репозиторию.
Подводя итог, можно дать простой ответ на вопрос этой главы. Системы управления версиями файлов нужны для того, чтобы автоматизировать рутинную работу по отслеживанию изменений файлов и облегчить жизнь разработчику. Но не надо обольщаться, использование систем управления версиями файлов не заменяет документирование проекта, а всего лишь помогает быстро и просто получить ответы на вопросы, кто, когда, что и зачем изменял в файлах.
Введение в SVN
Subversion (SVN) — бесплатная система управления версиями файлов с открытым исходным кодом. SVN позволяет управлять файлами и каталогами, а также сделанными в них изменениями во времени. SVN предоставляет следующие возможности:
Для погружения в использование SVN перечислим приводимые в статье основные термины и команды SVN:
Работа с SVN рассмотрена на основе демонстрационного репозитория demo_repo и тестового проекта demo_project, который изначально содержит один файл readme.txt. Положим, что с проектом работают два программиста: Вася и Петя.
В статье содержатся полезные заметки о практической работе с SVN. Заметки составлены на основе личного опыта использования SVN, выделены в отдельные абзацы и помечены следующим образом:
Кому-то они покажутся не важными, но для начинающих использовать SVN рекомендую эти заметки учитывать. Так вы избежите неприятных сюрпризов при первоначальном знакомстве с SVN. Итак, начнем с азов.
Репозиторий SVN
Основными объектами при работе с SVN являются рабочая копия (WC) и репозиторий.
В репозитории SVN хранятся все структуры папок и файлов. Репозиторий хранит все изменения, зафиксированные в нем, с момента создания.
Для отслеживания изменений во времени каждой операции, которая изменяет содержимое репозитория, присваивается уникальный «номер ревизии», запоминаются время и автор изменения. Все ревизии папок и файлов в репозитории доступны любому пользователю.
SVN запоминает все изменения, даже самые небольшие. Для облегчения поиска нужного состояния проекта рекомендуется заполнять строку комментария к любым изменениям в репозитории. Пустая строка комментария к фиксации изменений является признаком дурного тона. Данные виды фиксаций очень сложно отслеживать и искать.
В случае удаления папок или файлов из ре-позитория они будут удалены только в текущей ревизии. И в случае необходимости папки и файлы могут быть легко восстановлены.
Основной областью работы пользователя является рабочая копия. Любые изменения папок, файлов и их содержимого в рабочей копии недоступны для других пользователей до тех пор, пока эти изменения не будут зафиксированы в репозитории.
Добавлять, перемещать и удалять папки и файлы проекта лучше в рабочей копии. Использовать для этих целей репозиторий не рекомендуется. Использовать возможности репозитория для целей управления папками и файлами можно только в случае, если нужное действие сложно сделать в рабочей копии. К таким действиям относится копирование и перемещение папок и файлов вне пределов рабочей копии.
При работе с репозиторием помните, что у папок и файлов есть история изменений. Если вы удалите файл и создадите новый файл с таким же именем, это будут два разных файла, с непересекающейся историей.
Подсказка. Не стоит в комментариях писать дифирамбы результатам вашей работы. Комментарий должен кратко описывать вашу работу и ее результаты. Если комментарий получается слишком длинный, то стоит рассмотреть вопрос фиксации проекта по частям. Дифирамбы можете писать в сопроводительной документации на проект.
Создание репозитория
Репозиторий SVN может быть как сетевым, так и локальным. Сетевые репозитории нужны для использования командой разработчиков или в случае, когда необходим доступ к репозиторию с другого компьютера. Локальные репозитории удобно использовать тогда, когда разработчик один. В данной статье, несмотря на то что разработчиков двое (Вася и Петя), используется локальный репозиторий demo_repo. Это сделано потому, что цель статьи — показать основы работы с SVN, а для этого локального репо-зитория более чем достаточно. Локальный репозиторий можно сделать в любом месте на любом жестком диске. Для этого нужно создать папку репозитория, в нашем случае это D:demo_repo, и выполнить в ней команду Create repository here (рис. 1). Все, репозиторий создан (рис. 2). Можно приступать к работе над проектом.
Рис. 1. Создание локального репозитория
Рис. 2. Локальный репозиторий SVN
Важное замечание. Операции над папками репозитория, в обход команд клиента SVN, могут привести к повреждению репозитория и возможной потере информации в нем. Репозиторий использует специальный алгоритм хранения файлов. При обновлении версии файла он не создает новый файл, а создает файл разницы между этими двумя файлами. Эта разница и сохраняется в репозитории. Это сделано для экономии места и экономии трафика (если используется сетевой репозиторий).
Работа с репозиторием
Работа с репозиторием является обязательной составляющей работы с проектами, находящимися под контролем SVN. Для работы с репозиторием используется браузер репозитория (repo-browser). Чтобы им воспользоваться, заходим в корневую папку любого жесткого диска и путем нажатия правой кнопки мыши запускаем браузер (рис. 3).
Рис. 3. Вызов браузера репозитория
Для просмотра репозитория нужно указать, к какому именно репозиторию будет обращение (рис. 4). Префикс file:/// указывает на то, что репозиторий D:demo_repo является локальным. Наш репозиторий пока пуст (рис. 5).
Рис. 4. Диалоговое окно задания используемого репозитория
Рис. 5. Начальное состояние нового локального репозитория
Важное замечание. Будьте осторожны при работе с браузером репозитория: несмотря на то что в репозитории ничего нельзя удалить навсегда, вы можете случайно нарушить работу ваших коллег.
Создание проекта
Для того чтобы поместить свои папки и файлы под контроль SVN, необходимо создать первоначальный проект. Сделать это можно двумя способами.
Создание проекта в репозитории
Этот способ подходит для создания изначально пустого проекта. Заходим в репо-зиторий. В корневой папке репозитория, используя команду CreateFolder (рис. 6), создаем корневую папку нашего проекта demo_project (рис. 7). Обязательно оставляем комментарий к действиям по изменению ре-позитория (рис. 8).
Рис. 6. Создание папки непосредственно в репозитории
Рис. 7. Диалоговое окно задания имени создаваемой папки
Рис. 8. Диалоговое окно для задания комментария при создании папки
Подобную последовательность шагов проделываем для обязательных папок, назначение которых описано ниже, в итоге получим пустой проект в репозитории (рис. 9).
Рис. 9. Состояние репозитория после создания проекта непосредственно в репозитории
Импорт проекта
Этот способ больше подходит для случая, когда есть готовый проект и нужно поместить его под контроль SVN. Возьмем тестовый проект demo_project1 (рис. 10). С помощью команды Import импортируем его в репозиторий (рис. 11). Не забываем про указание имени папки, в которую мы импортируем проект, и о комментарии к изменению репо-зитория (рис. 12).
Рис. 10. Проект на жестком диске перед импортом в репозиторий
Рис. 11. Импорт проекта в репозиторий
Рис. 12. Диалоговое окно для задания комментария при импорте проекта
После окончания импорта в окне протокола видно, что происходило с папками и файлами проекта (рис. 13). Текущее состояние репозитория показано на рис. 14. Как видите, все папки и файл проекта были добавлены в репозиторий одной командой. Тут нужно уделить внимание тому, что при импорте проекта в репозиторий будут добавлены все файлы, которые находятся в папках проекта.
Рис. 13. Окно протокола импорта проекта
Рис. 14. Состояние репозитория после импорта проекта
То, что импорт проекта завершен удачно, не означает, что папка, которую вы использовали для импорта проекта, является теперь рабочей копией. Любые изменения в этой папке не могут быть зафиксированы в репозитории SVN. Работа с рабочими копиями описана в следующей части статьи.
Важное замечание. При импорте проекта убедитесь в том, что проект с таким именем не существует, и в том, что вы создаете проект в корневой папке репозитория.
Важное замечание. При импорте проекта в репозиторий будут добавлены все файлы, которые находятся в папках проекта. Поэтому перед импортом проверьте проект на предмет чистки от ненужных файлов. Какие файлы не имеет смысла хранить в SVN, будет рассмотрено ниже.
Подсказка. При создании проектов очень удобно использовать шаблоны проектов. В таком случае, используя шаблон, вы импортируете проект в репозиторий. Это избавит вас от необходимости каждый раз создавать повторяющиеся от проекта к проекту папки и файлы. Например, используемый мной шаблон для проектов на ПЛИС:
ProjectName branch teg trunk
beh behaviour models of project units
core external not under development IP cores
doc project documentation
include common header files
netlist ready netlist of project modules
quartus quartus projects files
rtl rtl models of project units
sim simulation scripts for verivication
testbench verification enviroment for project
Подсказка. Если вы неправильно создали проект (не те имена папок, не туда поместили по ошибке), то сначала удалите командой Delete все неправильно созданное в репозитории и только потом создавайте проект заново. Или воспользуйтесь командой Move для того, чтобы перенести папки проекта в другое место (в TortoiseSVN в браузере репозитория команда Move выполняется по технологии drag-and-drop).
Создание рабочей копии
Для того чтобы начать работу с проектом, нужно создать рабочую копию. Для этого создаем корневую папку проекта на диске. Заходим в эту папку и используем команду Checkout (рис. 15).
Рис 15. Создание рабочей копии проекта в папке на диске
С помощью браузера репозитория выбираем интересующий нас проект, папки и файлы в этом проекте. С помощью браузера ревизий Show log выбираем нужный номер ревизии (рис 16). В данном случае выбрана Head (головная/последняя) ревизия. Нажимаем на OK. Все, рабочая копия создана и находится под контролем SVN, о чем говорит иконка SVN на файлах и папках (рис. 17).
Рис. 16. Диалоговое окно для задания источника папок/файлов для рабочей копии проекта
Рис. 17. Созданная рабочая копия проекта, которая находится под контролем SVN
Теперь можно свободно изменять, удалять, модифицировать папки и файлы проекта, добавлять новые папки и файлы, не опасаясь того, что ваши изменения будут мешать работе ваших коллег.
Подсказка. Узнать, к какому репозиторию и проекту относится папка или файл, можно из свойств папки/файла, которая находится под контролем репозитория (рис. 18).
Рис. 18. Доступ к SVN-свойствам файла для их просмотра
Подсказка. Если нужно передать куда-то файлы проекта, воспользуйтесь командой Export (рис. 19). Эта команда не создает служебных папок.
Рис. 19. Экспорт проекта из репозитория в папку на диске