Миграция из мерзавца в Perforce

Question

У меня есть задача по переносу моей команды и источника из git в Perforce, и я ищу идеи о том, как перенести историю git в p4.

Я был бы рад только перемещению мастер ветки. Однако даже это оказывается проблематичным.

Я использую замечательный инструмент git-p4. Я создаю область назначения в моей рабочей области p4 и использую git p4 clone //depot/StuffFromGit, чтобы начать отслеживать ее в git-p4. Я прививаю все изменения моего git-репозитория в клон git-p4. Затем я могу git p4 submit и все готово, все изменения помещаются в p4.

Отлично работает, когда история git выглядит так, красиво и линейно:

A---B---C---D

Проблема связана с тем, что над проектом работают несколько человек. Даже при том, что они работают над мастером, это все еще создает ветви, которые разделяются и объединяются Тем не менее, git-p4 смело справляется с этим:

A---B---C---E
     \--D--/

git p4 перемещается в порядке, фиксируя ABCDE по порядку (или ABDCE, история любого человека в первую очередь).

Проблема возникает, когда, например, C и D одновременно изменяют один и тот же файл, а E - это слияние по-настоящему добросовестно. git p4 rebase терпит неудачу здесь; он перематывает коммиты, но во время воспроизведения сначала применяет C, затем пытается D и обнаруживает конфликт. Затем он остановится, попросив меня слиться. Хорошо, E содержит слияние, но оно просит меня слить вручную! 'git p4 submit' завершится аналогичным образом, только теперь p4 отклоняет изменение перед слиянием.

Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging main.cpp
CONFLICT (content): Merge conflict in main.cpp
Failed to merge in the changes.
Patch failed at 0005 Changing main

Так что теперь я застрял. Есть ли способ дезинфицировать историю git или заставить git-p4 понять это? Это расстраивает, так как слияния есть.

Мысли, которые у меня были:

• Используйте git filter-branch, чтобы удалить все упоминания о конфликтующих файлах. Я бы получил комментарии к истории, хотя пропустил много изменений файла. Приблизительно с 3000 коммитами в истории я бы удалил историю всех ключевых (занятых) файлов. В конце импорта отфильтрованных файлов я бы добавил недостающие файлы обратно, сделав окончательную фиксацию HEAD.
• Сбросить историю, сделать один коммит p4 из HEAD (просто, но грустно).
• Не переходите к p4: я работал над этой идеей как можно дольше.

Ничего из этого не очень хорошо. Любые идеи о том, как git 'gt p4 rebase' или 'git p4 submit' работают?

Answer 1

Опция «просто выбросить старую историю» не так плоха, как кажется: вы можете просто держать git-репо рядом с ним вечно, на случай, если кому-то понадобится копаться в старой вещи. К сожалению, просто невозможно представить сложное представление git об истории в линейных системах старого типа, таких как svn и p4.

Основная причина оглянуться на старую историю - это такие вещи, как «git annotate» (я полагаю, что у p4 есть похожий инструмент). Если это все, что вы хотите, то, возможно, то, что вы действительно хотите сделать, это раздавить все ваши коммиты слияния до одного из их родителей (поэтому они выглядят как один коммит вместо слияния). Это больше похоже на то, что svn и p4 записали бы в своей собственной модели истории, где слияния выглядят как один коммит в линейном потоке. Вы, вероятно, можете сделать это с помощью git-filter-branch или подобного. Конечно, это потеряло бы всю историю, которая произошла в дочерних ветвях ... но пользователи p4 привыкли не иметь этой информации.

Answer 2

Вы проверяли инструмент "портной"? Это сборка для синхронизации разных VCS: es. Он должен иметь поддержку Perforce.

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

Answer 3

Я думаю, вам следует попробовать Tortoise SVN, а затем Hg, подумав об обновлении одной ветки, или вы можете сказать миграцию. Убедитесь, что у вас есть вся клонированная свалка, чтобы быть в безопасности. Удачи!