что такое ревизия в svn
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.
SVN hooks: изменение комментария к ревизии
Не секрет, что по умолчанию изменение текста комментария к ревизии в SVN не разрешено. Пост предназначен для тех, кто хочет сделать это возможным, но не знает как.
Для начала немного освежим память
Что такое hook.
Нет, это не фильм Спилберга, мы же на хабре. Это крючок, на который поймали событие 🙂 Просто програмка, которая запускается при возникновении определенного события в системе версионного контроля. Поддерживаются они не только SVN, поэтому можете поиграться с хуками например в GIT.
Если в корне вашего репозитория есть папка hooks, знайте — это и есть гнездо хуков. В этой папке могут храниться шаблоны хуков, названия которых соответствуют отслеживаемым событиям.
Это означает, что на базе этих шаблонов вы можете сделать свой хук. Как вы уже догадались pre-хуки срабатывают перед событием. post-хуки — после события.
* start-commit — запускается до начала транзакции, может быть использован для проверки прав.
* pre-commit — запускается в конце транзакции, но до commit, часто используется для валидации данных, например для проверки не пустых лог-сообщений.
* post-commit — запускается после транзакции, может быть использовано для отправки e-mail или для резервирования хранилища.
* pre-revprop-change — запускается до изменений в ревизии, могут быть использованы для проверки доступа.
* post-revprop-change — запускается после изменений в ревизии, могут быть использованы для отправки e-mail.
* post-lock, post-unlock, pre-lock, pre-unlock — запускаются, когда репозиторий работает с блокировками
Не лишним будет упомянуть, что у юзера, который подключается к репозиторию, а значит и запускает хуки, должны быть права на исполнение.
Изменение комментария к ревизии
Перейдем к решению нашей задачи. Воспользуемся pre-revprop-change хуком, для того, чтобы ввести дополнительный контроль. Кроме того, следует помнить, что в хук передаются следующие параметры
1. Путь к репозиторию
2. Ревизия, свойства которой будут изменяться
3. Имя пользователя, который будет производить изменения
4. Название изменяемого свойства
5. Код действия: A (добавлено), D (удалено), или M (модифицировано)
Хук справа.
В *nix системах достаточно создать в папке hooks соответствующий файл без расширения, например pre-revprop-change
Хук слева.
В Windows файл в папке hooks должен быть исполняемым, например pre-revprop-change.bat
Если вы используете VisualSVN сервер, батник по умолчанию работать не будет. И папку hooks создавать не надо. Надо просто открыть VisualSVN Server Manager, зайти в свойства репозитория, для которого хотите создать хук, выбрать вкладку Hooks. Дважды кликните на Pre-revision property change hook и просто скопируйте туда код батника.
Дополнение: при активации хука в VisualSVN Server Manager, сервер сам создаст папку hooks и породит там стандартные шаблоны.
За наводку спасибо chemodax
Совместная разработка с помощью Subversion
Управлять наёмными рабочими и распределенными проектами — это просто и весело. Стоп, что за чушь? На помощь приходит хороший контроль версий — именно то, что вам нужно, чтобы правильно вести ваши проекты.
Далее — перевод статьи Collaborate and Connect with Subversion. Это мой первый перевод, поэтому был бы очень рад вашим замечаниям.
Представьте, что у вас своя веб-студия. Быть может, это лишь вы и еще пара людей. Из-за столь небольшого состава вы часто прибегаете к помощи наёмных рабочих (субподрядчиков). Благодаря этому, вы можете браться за большее количество проектов, зарабатывать больше денег и аккуратно масштабировать свой бизнес. Однако управление даже небольшим количеством наёмных рабочих требует большого напряжения и сил. На определенном этапе вы столкнетесь с тем, что субподрядчик не выполняет свои обязанности в срок, не соблюдает ваши стандарты качества, или, что еще хуже, исчезает, так и не завершив работу. Вам могут помочь тщательные проверки данных, твердые соглашения и активный менеджмент. А технологии, в свою очередь, могут улучшить совместную деятельность для того, чтобы ваши проекты всегда были под контролем. Встречайте — Subversion.
Subversion создает благоприятные условия для совместной работы
Subversion (SVN) — это система контроля версий, которая позволяет хранить и следить за изменениями вашего кода, совместно использовать файлы проекта и предоставлять к ним доступ. Это очень просто. Вы пишете код и отправляете (commit) его в ваш SVN-репозиторий (место, в котором хранятся файлы проекта). Участники вашей команды могут скачать эти файлы, посмотреть, что вы сделали, внести свои изменения и затем, снова отправить эти изменения SVN-репозиторию. Каждый такой «commit» считается ревизией. SVN отслеживает эти ревизии и присваивает им номера, так что вы всегда можете «откатиться» к предыдущей версии вашего кода.
Видимость — это хорошо
Благодаря Subversion, все участники вовлечены в проект: как только кто-то вносит изменения, остальные сразу могут их увидеть (см. ниже Необходимые инструменты). Если у вас надежные субподрядчики, вы не будете лишний раз волноваться. Однако, при работе с непроверенными людьми, такая видимость позволяет избежать всех разногласий, проблем в проекте и ошибок в коде до того, как настанет время принимать работу.
Пусть SVN будет обязательным
Если субподрядчики действительно хотят сотрудничать с вашей студией, заставьте их следовать вашему рабочему процессу и использовать те же средства. Различия могут серьезно затруднять деятельность небольших компаний, особенно компаний по работе с клиентами.
Некоторые наёмные рабочие, быть может, захотят отправить вам результаты работы. zip-файлом по почте или выложить их на удаленном сервере, чтобы вы скачали и посмотрели. Это, конечно, хороший способ, но так принадлежащий вам код находится за пределами вашей организации. Фактически, вы теряете контроль над проектом. Каково же решение? Сделайте SVN частью вашего рабочего процесса. Помимо обычных преимуществ, вроде версионности и одновременной работы множества людей над проектом, SVN заставляет ваших субподрядчиков быть более ответственными, а также позволяет держать код и файлы для ваших клиентов под контролем и в вашей собственности.
Поскольку вы — наниматель, вы имеете полное право оговорить правила сдачи, используемые средства, а также когда и как работа должна быть сделана. Ваши субподрядчики оценят серьезный рабочий процесс и будут более ясно осознавать, что действуют вместе с вами.
Есть ли исключения из этого правила?
Процесс не должен быть применен только потому, что это процесс. В зависимости от уровня ответственности наёмного рабочего, вы можете решить не включать его в ваш SVN. А когда это сделать — вы увидите сами.
Установите ожидания
Каждый использует Subversion по-разному. Кто-то любит отправлять изменения проекта по несколько раз за день. Другие же предпочитают работать над проектами и отправлять изменения в конце рабочего дня. Многое зависит от типа проекта, над которым вы работаете, а также от количества людей, работающих над одним и тем же кодом. Я обнаружил, что чем ближе завершение проекта, тем больше изменений, происходящих в течение короткого периода времени. На этом этапе я отправляю изменения в SVN чаще.
Установите, насколько часто вы ожидаете обновлений от ваших наёмных работников. Я рекомендую не менее одного раза в день, пока они работают над проектом.
Плюсы и минусы
Мы ведь не просто получаем больше управления в свои руки? Конечно. Теперь вы можете оценивать качество и количество выполняемой субподрядчиками работы за определенное время. Вы способны быстро оценивать продуктивность ваших наёмных рабочих, и им это тоже полезно — вам не нужно приставать к ним с просьбами закончить работу, пока вы работаете вместе.
Субподрядчики могут беспокоиться, что при таком порядке им не заплатят за работу. Ведь, действительно, если у вас последняя версия их исходных кодов, что мешает вам присвоить себе работу, не заплатив при этом. Subversion, сама по себе, не разрешает данную ситуацию, хотя мошенничество может иметь место при любой другой организации рабочего процесса. Убедитесь, что в вашем контракте четко описаны правила сдачи и порядок оплаты работы. В интернете полно ресурсов, где вы можете узнать, как правильно составлять контракт, чтобы полностью защитить себя. Если вы все еще работаете с субподрядчиками без контракта, вам впору задуматься о том, все ли правильно вы делаете.
Необходимые инструменты
Чтобы начать пользоваться SVN и понять её основы, прочтите статью «I Wonder What This Button Does» автора Mike West. Ещё один хороший и бесплатный ресурс — O’Reilly «Version Control with Subversion». Не забудьте прочитать хороший обзор по работе с SVN в главе Фундаментальные понятия.
SVN, сама по себе, может быть сложной при попытках управлять пользователями с различными правами доступа. К примеру, вы наверняка захотите, чтобы ваш субподрядчик имел доступ только к тому проекту, над которым он работает, а не ко всему репозиторию. Для упрощения работы с репозиторием и управлением пользователями я рекомендую Warehouse, веб-интерфейс к Subversion от Active Reload. Warehouse позволяет вам легко управлять репозиторием, следить за изменениями, и, самое важное, добавлять пользователей и устанавливать им права доступа. Управление пользователями в SVN может быть довольно утомительным, но, благодаря данному интерфейсу, вы можете легко добавлять и удалять их. Он также предоставляет RSS-ленту с изменениями репозитория, которая позволит вам и вашей команде отслеживать файлы, над которыми ведется работа в данный момент, а также все изменения, происходящие в системе. Существуют также решения, использующие свой хостинг, например, Beanstalk. Они будут располагать у себя ваш SVN-репозиторий и предоставлять пользовательский интерфейс к нему.
Хотя я настоятельно призываю людей сначала научиться пользоваться SVN из командной строки, вы также можете попробовать новое приложение под Mac OS X — Versions (в настоящее время в бета-версии). Оно предоставляет графический интерфейс к большинству команд SVN.
Встраивание в текущую работу
Добавление Subversion в ваш текущий рабочий процесс не должно происходить со скрежетом. При наличии определенных навыков, можно соединить SVN с вашими инструментами управления проектами. Существуют так называемые «события репозитория», при возникновении которых, SVN позволяет запускать любые ваши скрипты. Например, скрипт, который будет писать новое сообщение в приложение-чат Campfire от 37Signals каждый раз, когда вы отправляете изменения в SVN-репозиторий. Таким образом, вы оповещаете ваших сотрудников о сделанных вами изменениях. С помощью Google, вы найдете множество других скриптов, написанных под различные инструменты, включая интеграцию средства управления проектами Basecamp с SVN.
Существует несколько различных типов встраивания SVN, но, всё же, наиболее распространен тот, что запускает скрипт после успешной отправки изменений репозиторию. Благодаря таким скриптам, возможности по совместному использованию SVN и ваших привычных рабочих средств практически неограниченны.
Хватит читать, пора действовать
Subversion — это не только отличное средство для версионности и контроля кода ваших проектов, оно также позволяет контролировать и улучшать взаимодействие между вами, вашими сотрудниками и наёмными рабочими. Пора немного улучшить жизнь себе, своей компании и своим субподрядчикам — начните применять SVN в своей работе уже сейчас.
Установка и настройка 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.