Как я могу экспортировать большой репозиторий Perforce в другую систему контроля версий без потери истории?

Question

На работе у нас большой репозиторий Perforce (около 40 тыс. Списков изменений, общий объем хранилища ~ 145 ГБ). Как правило, мы довольны Perforce лишь незначительными трудностями, но мы планируем перейти к более распределенной модели разработки и, как следствие, хотели бы перейти и к более распределенной системе управления версиями.

До сих пор я смотрел на обычных подозреваемых (git, mercurial и, возможно, базар, так как у меня есть хороший опыт работы с ним), но наше основное препятствие в настоящее время состоит в том, чтобы извлечь историю версий из Perforce и импортировать в различные DVCS, так что мы не теряем историю. Мы также предпочли бы, чтобы сервер Perforce не зависал, если нам совершенно не нужно его хранить - мой опыт такого рода миграции заключается в том, что через некоторое время никто не смотрит на старый репозиторий, поэтому вы потеряете историю таким образом.

Поскольку в хранилище имеется несколько проектов, идея состоит в том, чтобы разделить его на несколько проектов DVCS, когда мы экспортируем историю, поскольку не всем нужно видеть каждую часть истории. Однако наш крупнейший проект все еще содержит около 2/3 принятых изменений, а также занимает около 2/3 хранилища. У этого также есть наибольшее количество отделений - вероятно, около 30.

Пока что я попробовал следующее - все в Windows, так как мы работаем только для Windows:

• Импорт в Mercurial с использованием расширения hg convert. Похоже, что это работает очень хорошо для основной ветви проекта, которую я конвертирую, но попытка преобразовать ветви Perforce в именованные ветви Mercurial с использованием карты ветвления все еще производит плоский импорт при каждой регистрации в ветви по умолчанию. Может быть, это потому, что я неправильно настроил карту ветвей, но hg help convert предполагает, что вы можете превратить репо Perforce в «плоскую» структуру без ветвей, использующих этот импортер, что на самом деле недостаточно для нашего использования.
• Импорт в Git с использованием git-p4.py. Документы Perforce, использующие git в качестве распределенного внешнего интерфейса для Perforce и основанные на закрытии последней ревизии (репо) репо, позволяют использовать репозиторий git. Попытка импортировать весь подпроект с ответвлениями ломает импортер, поскольку у него заканчивается память, поэтому я даже не могу сказать, удастся ли ему правильно импортировать наш репозиторий.
• Затем у меня был блестящий умственный импорт импорта репозитория Perforce в SVN со всеми ветвями, сопоставленными с соответствующими ветвями SVN, поскольку каждая система управления версиями под солнцем может импортировать из SVN. Это будет использовать только SVN в качестве промежуточного шага в преобразовании, а не в качестве целевой VCS - иначе мы бы ничего не выиграли от этого преобразования. Использование p42svn.pl, которое довольно рано сломалось в процессе, так как нашему серверу Perforce, похоже, не нравился сценарий, создающий новое соединение для каждого файла / ревизии.
• Я еще не изучал возможность экспорта истории в Базар, так как это тоже немного заурядно.

Итак, мои вопросы:

• Есть ли хороший инструмент, кроме p42svn.pl, для экспорта репозитория Perforce в SVN? Я не возражаю против использования SVN в качестве промежуточного репо, поскольку это делает экспорт во все DVCS, на которые мы смотрим, достаточно просто.
• Кто-нибудь успешно экспортировал ветки из Perforce в названные ветки Mercurial, и если да, то как вы это сделали? Документы по расширению конвертации кажутся немного скудными, и я не могу найти хороший / рабочий способ сделать это.

Answer 1

Как вы знаете, переключение систем управления источниками - это огромная задача, которую нельзя воспринимать легкомысленно. Существует значительный риск и время простоя, так как 1) вы выполняете фактический переход и 2) снова, когда все переоснащаются и переходят на новую скорость с новой системой.

Поскольку вы все еще изучаете свои варианты, я бы серьезно вздохнул и заглянул в P4 Sandbox , чтобы посмотреть, будет ли это соответствовать вашим требованиям.

Более подробная информация о P4 Sandbox приведена ниже.

Обзор
- Демонстрация возможностей P4Sandbox (видео)

Сообщения блога
- P4Sandbox Частное локальное ветвление, распределенная разработка и многое другое
- Первая отправка P4Sandbox
- Распределенная разработка и P4Sandbox
- Частная ветвь с P4Sandbox
- Работа с заданиями в P4Sandbox

Обсуждение на форуме
- Новые возможности Обсуждение на официальных форумах

Answer 2

Клянусь, ваш репозиторий действительно имеет размер почти 200 гигабайт?Мне жаль первого дурака, который набрал git pull, чтобы получить копию репозитория, и обнаружил, что теперь он загружает данные объемом 150 гигабайт.

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

Я привык быть сторонником того, чтобы всегда получать как можно больше истории, но однажды мне пришлось преобразовать репозиторий StarTeam в ClearCase.и это просто невозможно сделать.Инструменты командной строки в StarTeam были плохими, и API просто не мог сделать то, что мне нужно.

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

Однако, если вы действительно хотите пройти через это, это действительно не должно быть так.плохой.Возможно, вы могли бы написать скрипт Python или Perl, чтобы выполнить преобразование для вас.

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

Если ваш последний набор изменений P4 равен 1000, вы можете зациклить хотя наборы изменений 1до 1000Perforce иногда пропускает набор изменений, но это довольно легко обнаружить.У каждой ревизии есть дата, имя человека, который сделал этот коммит, и его комментарий.Получив эту информацию, вы вносите свои изменения в репозиторий Git и изменяете дату, автора и комментарий этого коммита.

Кстати, поскольку вы переходите в Git,Я надеюсь, что вы разбите свой репозиторий на отдельные репозитории.И, если вы зафиксировали построенные объекты, удалите их из репозитория Perforce, прежде чем перемещать их в Git.Вы никогда не должны хранить встроенный объект в хранилище - особенно если они двоичные.Они занимают много места и очень быстро устаревают.

Answer 3

Мы (я работаю на Perforce) создали продукт, предоставляющий git-интерфейс для депо Perforce.

http://www.perforce.com/product/components/git-fusion

Я использовал это внутренне более года, это здорово,поскольку вы можете опробовать новый подход DVCS (сколько репо вы хотите) с «живым» бэкэндом Perforce.Я был единственным членом команды, использующим git, в то время как все остальные использовали p4 или p4v.Поэтому люди могли бы работать с помощью git и постепенно выбирать вашу конфигурацию миграции.

Существует поддержка отображения ветвей между двумя системами: http://www.perforce.com/perforce/doc.current/manuals/git-fusion/index.html#chapter_dyn_ngj_3l.html#section_kkz_gqv_rl

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