До сих пор работал c SVN и TFS и был вполне доволен. Но количество активных проектов растет, и некоторые из них придется поддерживать даже во время отпуска и летних поездок. Потому встал вопрос об использовании децентрализованной системы контроля версий, и доступа к репозиторию независимо от интернет соединения.
Кроме того, контора, в связи с ремонтом, переехала на несколько месяцев в новое здание, сервера также переехали. Потом, когда ремонт закончится, будем переезжать назад. Мне все это не очень нравится, и я решил найти более надёжный хостинг для кода.
Выбор пал на BitBucket.com. На выбор предлагается Mercurial или Git. До 5 пользователей репозитория - бесплатно.
Мой выбор системы контроля версий - Mercurial. У него очень удобный родной графический клиент TortoiseHg под Windows.
Как перенести репозиторий с удаленного SVN на Mercurial BitBucket.
Нам понадобятся SVN утилиты командной строки svnrdump и svnadmin. Они устанавливаются вместе с TortoiseSVN, если отметить соответствующую опцию в процессе установки.
Если доступ к SVN осуществляется через SSH, необходимо:
- чтобы утилиты PuTTY pageant.exe и plink.exe были в PATH.
- Вероятно также, что нужна системная переменная SVN_SSH с полным путем до plink.exe. У меня например SVN_SSH = "C://Program Files (x86)//PuTTY//plink.exe". Здесь обратите внимание на двойные слеши.
- В файле ..\AppData\Roaming\Subversion\config, в секции [tunnels] нужно раскомментировать строку ssh = $SVN_SSH ssh -q
- pagreant.exe должен быть конечно же запущен вместе с приватным ключом
"C:\Program Files (x86)\PuTTY\pageant.exe" c:\key_private.ppk
Это пожалуй самая трудная часть, заставить работать SVN c SSH.
А теперь поехали переносить репозиторий.
1. Сделаем дамп удаленного SVN репозитория в файл repo.dump (работает с SVN версии от 1.7)
svnrdump dump
http://example.com/svn-repo/ > repo.dump
2. Создадим новый локальный SVN репо и восстановим в него данные из дампа
svnadmin create c:\svn-repo
svnadmin load c:\svn-repo < repo.dump
3. Теперь конвертируем имеющийся локальный SVN репозиторий в Mercurial:
hg convert c:\svn-repo c:\hg-repo
Если convert не работает, то его надо разрешить. Для этого в Hg Workbench меню File->Settings->Extensions тут пометить convert.
4. Перенесем получившуюся лоакльную Mercurial репу на BitBucket.
Сначала создаем новый репо на BitBucket.
Потом делаем push
cd /path/to/my/new-local-repo
hg push ssh://hg@bitbucket.org/username/new-repo
Это самая долгая операция, тут хорошо иметь быстрый интернет канал.
Если push делать в Hg Workbench, то там виден прогресс сколько файлов обработано.
5. Делаем репу на BitBucket репозиторием по умолчанию.
В каталоге репозитория есть конфиг файл .hg/hgrc, в нем прописываем в разделе [paths]
[paths]
default = ssh://hg@bitbucket.org/username/new-repo
PS Если плинк жалуется, что серверный ключ не закеширован и выдает что-то вроде
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 хх:хх:хх:хх:хх:хх:хх:хх:хх
Connection abandoned.
Нужно запустить плинк напрямую в командной строке и подтвердить кеширование - ответить "y" на вопрос
plink -agent bitbucket.org
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y