Переход с SVN на Perforce - советы? Опыт?
У нас есть довольно большой репозиторий SVN, который мы хотим перенести на принудительную версию. Мы очень хотим сохранить ~ 20k ревизий, веток и т. д., Но в некоторых начальных тестах сценарий svn2p4, предоставляемый perforce, не смог воспроизвести полную структуру.
Были ли люди успешны с этим инструментом или были другие, которые не выполнялись при поиске в Google? Приветствуются передовой опыт и советы.
Ответы 4
Виталий Покровский и Марк Фридрих создали svn2p4, Perl-скрипт, который будет «синхронизировать и воспроизводить» для импорта каждого набора изменений в принудительном порядке.
Вы можете найти его на perforce wiki. Об этом они также сделали презентацию на Конференция пользователей Perforce 2007 г..
обновление 2012: Еще одно решение - использовать p4convert-svn. Подробности здесь: p4convert-svn на сайте perforce
Как сказано в OP, svn2p4 у него работает некорректно: «в некоторых начальных тестах сценарий svn2p4, предоставляемый perforce, не смог воспроизвести полную структуру».
но это помечено как ответ - В: инструмент X не работает, что мне делать? A: используйте инструмент X. lol.
Я использовал этот сценарий для довольно большой миграции. Пришлось внести ряд исправлений и взломов. Если вам нужна моя версия сценария, дайте мне знать.
Пол, мне будет интересна ваша версия.
Мой самый большой совет - не делайте этого. С точки зрения удобства использования perforce намного хуже, чем svn. Я вынужден использовать его на работе, и он гораздо менее интуитивно понятен, чем интерфейс svn на основе файлов / проводника Windows. Настройка рабочих пространств не интуитивно понятна, и их сложно удалить. Иногда он сбивается с толку и ничего не фиксирует, даже если он был изменен. По умолчанию все доступно только для чтения. Он фиксирует файлы, которые извлечены, но не изменены. Я мог бы продолжить ...
Во-первых, Операция, вероятно, не может изменить решение. Во-вторых, я обнаружил, что P4 - отличный инструмент. Он отличается от SSafe и SVN, но, безусловно, неплохой инструмент. обычно компании уклоняются от этого из-за дороговизны.
На самом деле я лично никогда не работал с Perforce, но некоторые бывшие сотрудники Google и Microsoft на работе клянутся этим. Наша причина переключения во многом связана с плохим слиянием в SVN. Мы могли бы видеть конфликты при слиянии ветки с основной веткой, когда был изменен только один из файлов, и т. д. Слишком подвержены ошибкам.
+1, любой, кто считает Perforce хорошим, мало информирован. Мне приходится работать с ним каждый день, и хотя он лучше, чем CVS, это чушь по сравнению с Git.
Я согласен с Полом Беттсом. В другие годы я использовал RCS, CVS, SourceSafe, ClearCase, Subversion, Perforce и Mercurial. Perforce похож на ClearCase - он силен в ветвлении, но инсталлирует сохранение состояния рабочей копии клиента на сервере. Это может очень раздражать, когда файлы изменяются локально, но не извлекаются. Обработка Perforce изменений, внесенных в перемещенные / удаленные файлы, также довольно плохая. Я бы сказал, используйте Subversion, если это приемлемо для руководства.
Каждая ваша жалоба на P4 решается путем изменения клиентской опции. Отредактируйте параметры подключения: 1) P4 вернуть неизмененные файлы: «SubmitOptions: revertunchanged» 2) Записываемые файлы без отметок: установите флажок «allwrite». 3) ... и я мог бы продолжить .... Я использую P4 для ветвления и слияния (и для резервного копирования svn) svn запутывается, если его чертов .svn вообще затрагивается. У меня было так много проблем, что svn очистка не решит.
Я все использовал. Скалы воли. Вот почему Google, nvidia и сами окна управляются принудительно. Черт возьми, теперь вы можете использовать их шлюз git и позволить git Heads использовать git, при этом толчки автоматически перетекают прямо в perforce
Как упоминал fuzzymonk, кажется, единственный реальный вариант - использовать perl-скрипт svn2p4. Я использовал это несколько раз, и он работал хорошо, хотя и медленно, особенно со многими ветвями.
Одна вещь, которая была очень полезна в этом сценарии, - это возможность минимизировать время простоя практически до нуля, независимо от географического расстояния между серверами. Это возможно, потому что svn2p4 полностью возобновляем.
- Сначала вы делаете резервную копию своего svn-сервера
- Оставляя активный сервер включенным, вы запускаете импорт из svn в принудительную с помощью резервной копии.
- Когда этот импорт будет завершен, вы можете отключить рабочий сервер и завершить импорт, указав svn2p4 на активный сервер вместо резервной копии.
Это означает, что вам нужно отключить сервер только для тех нескольких ревизий, которые произошли с момента создания последней резервной копии. Это особенно полезно, если ваша миграция осуществляется на больших географических расстояниях (серверы svn и perforce находятся далеко друг от друга), потому что большая часть вашего импорта выполняется локально, возможно, на том же компьютере, а не через Интернет.
В данный момент мы находимся в середине большого импорта (20K ревизий, 18GB svn root), и мне любопытно, с какими проблемами вы столкнулись при начальных тестах.
Эта проблема, вероятно, полностью устранена, но, к вашему сведению, в записи блога Скотта Биласа есть много полезной информации: http://scottbilas.com/blog/subversion-to-perforce-post-mortem/
Он упоминает некоторые конкретные проблемы с svn2p4 и способы их решения (когда такие обходные пути возможны).
Я только начал использовать Perforce после многих лет работы с Subversion, так что я нахожусь на крутом этапе обучения.
Какие конкретные части структуры инструмент не смог воспроизвести? Это не удалось до конца или есть еще что-то. Может быть, некоторые особенности помогут вам дать ответ.