Перенос истории из CVS/PCVS/VSS/ClearCase/StarTeam/MKS в SVN

Доброго времени суток!

Данная статья посвящена одной небольшой задачке – переносу репозитория вместе со всей историей с одной системы управления версиями в другую, а точнее – в SVN. Речь пойдёт об использовании бесплатной утилиты Importer for SVN от Palarion, с помощью которой можно мигрировать с CVS / PCVS / VSS / ClearCase / StarTeam / MKS на SVN, не потеряв при этом журнала изменений кода. В моём случае потребовалось перенести проекты из Borland StarTeam.

Почему было сказано «нет» StarTeam и «да» SVN? Сначала думал пропустить данный абзац во избежание холиваров. Но, пожалуй, без этого статья была бы лишена, скажем так, области определения. В моём случае отказаться от StarTeam вынудил уход человека, его внедрившего и администрировавшего. Пара дней безуспешных попыток заставить работать сервис под другой учётной записью породили мысль о том, что задача восстановления репозиториев из бэкапов станет ещё большим вызовом. Конечно, радиус кривизны рук можно было значительно увеличить спустя какое-то время. Но оно нам надо, спрашивается, когда есть бесплатный, до безобразия лёгкий в установке и поддержке SVN? Тем более что у меня было предостаточно опыта его использования на предыдущих местах работы, а все два с половиной разработчика находятся в одной комнате.

Одно препятствие – жаль было терять историю изменений. Сначала думали залить в SVN текущие версии, а историю смотреть в StarTeam, переведя его предварительно в read-only. Но, как говорится, это не наш метод. И непродолжительный гуглопоиск навёл на выше в суе помянутый Palarion Importer for SVN.



Теперь непосредственно к сути. Имеем репозиторий в CVS / PCVS / VSS / ClearCase / StarTeam / MKS (с паролями и всеми доступами). Требуется его перенести в новый репозиторий в SVN.

Замечание 1: Судя по опциям в конфиге, существует возможность залития данных в уже существующий репозиторий, но я её не проверял.

Общий план действий:


0. Проверка системных требований.
1. Скачиваем утилиту.
2. Настраиваем общие параметры.
3. Настраиваем секцию SVN.
4. Настраиваем секцию VCS-источника.
5. Запуск утилиты.

0. Проверка системных требований


Из всех системных требований – установленная и настроенная JRE (т.к. утилита написана на Java) на той машине, где будет работать утилита. С этой машины должны быть доступны и источник, и приёмник.
В моём случае серверы и StarTeam, и SVN крутятся на одной машине, т.ч. для меня выбор был очевиден.

1. Скачиваем утилиту


Здесь по ссылке «Download» слева от основного текста. Сразу после указания имени/компании/e-mail начнется закачка. Никакого запроса на подтверждение на мыло не приходит, но есть проверка существования адреса. Затем просто распаковываем zip-архив на целевую машину.

2. Настраиваем общие параметры


В файле config.properties:

srcprovider=st
Это самое главное – источник данных. Здесь – StarTeam.

import_dump_into_svn=yes
Можно создать только дамп-файл(ы) – для этого ставим здесь no. Например, если возникают какие-то ошибки именно на стадии импорта в SVN (см. раздел «Выявленные проблемы»).

existing_svnrepos=yes
clear_svn_parent_dir=yes
По идее с помощью этих параметров можно залить в уже существующий репозиторий. Не пробовал. Я создавал локально новый репозиторий, а потом импортировал его на сервер с помощью удобного интерфейса.

3. Настраиваем секцию SVN


В файле же config.properties:

svnimporter_user_name=login
Я задействовал свой доменный (AD) логин. Но, сдается мне, можно любой указать.

svnadmin.executable=c:/Program Files/VisualSVN Server/bin/svnadmin.exe
Да. Я использую VisualSVN. Кому не нравится, прописывает путь к другому серверу.

svnadmin.repository_path=D:/SvnRepositories/Repository1
Как ни парадоксально, но это место расположения репозитория SVN.

svnadmin.parent_dir=.
Папка внутри SVN-репозитория. В данном случае – корневая.

svnadmin.tempdir=c:/temp/svnlocal
Временная помойка.

svnclient.executable=c:/Program Files/VisualSVN Server/bin/svn.exe
Вы не поверите…

svnadmin.verbose_exec=yes
В лог будет писаться подробная информация о ходе процесса.

Ещё есть файл config.autoprops. Там указаны MIME- типы и свойства для отдельных расширений файлов. Мне «заводских» настроек хватило за уши. Кому мало – может подсмотреть, например, здесь.

4. Настраиваем секцию VCS-источника


Для каждой из поддерживаемых VCS всё в том же config.properties есть отдельная секция. Камменты помогают понять что зачем.

В случае StarTeam указываем строку соединения (внутри вида можно также указывать отдельные папки):
st.url=LOGIN:PWD@SRV-NAME:49201/Project/View
st.tempdir=c:/temp/starteamtemp


Замечание 2: Пробовал задействовать параметры st.includes.regex/ st.excludes.regex, но так и не постиг тайны их формата (что такое RegEx я знаю, но к какой части URL он применяется, серия экспериментов ясности не дала). Пытался писать на их форум, но ответа не получил.

5. Запуск утилиты


Ну, вот – можно жать потными ручками красную кнопку. Для этого запускаем svnimporter.jar (для виндовз-пользователя уже заботливо приготовлен файл run.bat, где он передается JVM) и передаем ему 2 параметра:
%1 – команда. В нашем случае это full. Возможные варианты: list, incr.
%2 – наш поправленный выше конфиг: config.properties.

Т.е. как-то так:
SET JAVA_OPTS=-Xmx192m
java %JAVA_OPTS% -jar svnimporter.jar full config.properties


Замечание 3. Из известных мне команд есть ещё list для проверки корректности настроек экспорта/импорта.
Замечание 4. Есть ещё инкрементальный дамп, но в данной статье эта тема не раскрывается, хотя она может быть полезна тем, кто захочет синхронизировать две VCS на регулярной основе (по расписанию).

Критерий успешности

После завершения работы утилиты смотрим в журнал history.log и ищем сакраментальную строчку «successfully finished». Если её нет, то смотрим в svnimporter.log на предмет ошибки и устраняем оную.

Выявленные проблемы:


1. У меня утилита ругалась, что не может найти каких-то борландо-стартимовских классов. Я кинул в папку lib библиотеку starteam80.jar, которую я взял из места установки моего StarTeam Server 2005. Возможно, нужно было просто настроить переменные среды для Java.

2. На 3-м заходе возникли проблемы при импорте в SVN. Утилита ругалась на недопустимый символ UTF-8. Не знаю, кривизна ли это утилиты или у меня в хранилище битая версия была. В общем варианты решения:
  • задействовать st.includes.regex/ st.excludes.regex, чтобы пропустить проблемный файл, но, как я писал выше, мне удалось понять, как они работают (см. шаг 4).
  • убить проблемный файл в репозитории-источнике.
  • Создать только dump-файлы без импорта в SVN (см. шаг 2), hex-редактором поправить в дампе битый код и ручками залить dump-файлы в SVN — с помощью svnadmin.exe.

Комментарии 9

    +1
    И спасибо НЛО за приглашение!
      +1
      Теперь осталось мигрировать SVN-репозиторий в Mercurial/Git/Bazaar и жизнь будет вообще рай. :) Вообще сегодня как-то странно переползать на централизованные VCS-ы, когда вокруг столько распределенных, которые дают все то-же самое, что может SVN и плюс еще много. Я достаточно много проработал с SVN, даже пересадил прошлую фирму на него с VSS и в последствии занимался его администрированием, но попробовав распределенные системы я теперь вообще не вижу причины выбирать SVN вместо более гибкой и удобной распределенной системы.
        +3
        Причины по которым остаются на до-DVCS'ах есть, но они скорее психологические.

        Года 3 назад я тоже вытаскивал нашу команду (тоже в «прошлой фирме») с CVS на что-нибудь более современное. Посмотрел на Mercurial, не проникся: он был не очень популярен, хоть и обгонял Git по «дружественности» под Windows (тогда про Git Extensions еще не знали). HG оставил ощущение какой-то «чужеродности» — было ясно что принцип работы несколько другой, но описания делались или программистами в стиле «changeset, head, tag — тут все просто, нечего объяснять!» или маркетологами «мы все возбуждены, это революция!». Тогда остановился на SVN, поскольку мог сделать вводную презентацию, демо проект, помочь с перенастройкой CI сервера и т.д.

        Сейчас — да, после нескольких месяцев активной работы на Mercurial и мелких проектов с Git'ом, я понимаю, что назад уже не вернусь. Но тогда, без этого опыта, я просто не смог бы нормально рассказать про удобства организации работы с DVCS.
        –1
        Очень интересно. Мы тоже полгода как переехали со StarTeam, только не на subversion, а на git.
          0
          А я уж думал, что так никто и не напишет про Git и иже с ним :)

          В своё оправдание могу заметить, что у нас нет активной параллельной разработки в рамках отдельного проекта/приложения, поэтому SVN вполне устраивает. Да, и нет альтруистов двигать передовые технологии в массы – процветает так называемый прагматический консерватизм, как говорит мой шеф.
            0
            Сорри, относилось к этому посту
              +1
              На самом деле, активная парралельная работа, это не единственная причина пользоваться распределенными системами. Я тут как-то в Q&A отвечал: habrahabr.ru/qa/8493/#answer_36167
              Единственный случай, когда мне да кажется, что централизованная система оправдана — это при работе с большим количеством часто изменяемых бинарных файлов (например репозиторий дизайнера) — так как это сильно раздувает репозиторий. Правда я не уверен, что SVN тут тоже подходит, во всяком случае мой опыт администрирования SVN которым пользовался художник, рисовавший графику и модели к игре, был крайне негативный. Тут я думаю, нужно что то более простое и специализированное.
                0
                Всё, у меня аргументы кончились :) Хотя я и не собирался оспаривать преимущества распределенных VCS.
                  0
                  Я не холивара ради, честно :)

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое