Можно ли импортировать репозиторий MKS Integrity в git?

Мне нужно только исходное дерево и его история. На данный момент я не забочусь о требованиях/проблемах. Я немного поработал с командной строкой, чтобы выяснить, могу ли я получить список пакетов изменений для соединительной линии и некоторых из путей dev. Я думал, что должно быть возможно извлечь diff для каждого пакета изменений и использовать его для воспроизведения всех изменений с момента первого фиксации в git. Что-то вроде этого:

  • получить первый фиксатор и добавить его в git
  • получить следующий CP
  • получить diff для CP
  • применить diff к git работающему dir
  • добавить и зафиксировать изменения в git
  • повторить с (2.) до последнего CP

Вы также можете перезагрузить пакет изменений с помощью контрольной точки (для меня это было бы достаточно).

Простейшим способом было бы просто проверить CP и добавить/зафиксировать на git. Но тогда вы потеряете отслеживание операций добавления, удаления, перемещения и переименования.

Кто-нибудь знает, как получить унифицированный diff от "si diff"? Это уже сильно поможет.

Любые идеи?

Edit2:
Добавлен ответ, который показывает, как я на самом деле выполнял миграцию...

ОТВЕТЫ

Ответ 1

Проблема с MKS Integrity - это их уникальный репозиторий, в котором все находится:

  • ,
  • планы тестирования,
  • тестовые примеры,
  • ,
  • задачи разработчика,
  • запросы развертывания

Поскольку эти данные могут развиваться независимо друг от друга, в своем собственном темпе, импортирование их всех в один репозиторий Git было бы плохой идеей: вы можете клонировать весь контент репо (w20 > ) (даже если вы может ограничить глубину этого клона).
Это означает, что вы получите все документы, даже если вас интересует только код.
Экспорт MKS Integrity подразумевал бы определение первых много репозиториев Git как подмодулей.

Мне нужно только исходное дерево и его история.

Как обычно, я бы рекомендовал только импортировать:

  • основные ярлыки (для чего-либо старше года или любого другого периода, в котором вы чувствуете себя комфортно, вам не понадобится исследование полностью, потому что оно так устарело)
  • все ярлыки (майор и несовершеннолетние) за последние годы.

И я бы не импортировал все в один репозиторий Git, если вы не уверены, что все ваши источники представляют одну систему, разработанную как все (а не несколько "модулей", разработанных независимо)

Простейшим способом было бы просто проверить CP и добавить/зафиксировать на git.

Это будет способ продолжения.

Но тогда вы потеряете отслеживание операций добавления, удаления, перемещения и переименования.

Нет! Ты бы не! Git будет вывести эти операции.
В этом преимущество - файл Контент VCS.

Ответ 2

Я не могу опубликовать фактическую программу, которую я написал, потому что я не делал этого в свое время. Тем не менее, я могу опубликовать, как я это сделал. Это должно быть легко переделать на любой язык сценариев. Инструмент, который я написал, перемещал только одну ветвь за раз. Я бы сказал, какая ветка я хочу (например, 1.21.1) и начальная и конечная ревизии в ветке (например, 4 и 78 будут мигрировать все ревизии, начиная с 1.21.1.4 до 1.21.1.78). Чтобы иметь все ветки в одном репо, я бы предоставил каталог .git для импорта.

  • начать цикл от начала до конца до конца
    • CURRENTREV = BRANCH.loopcounter
    • создать каталог репо
    • переместите файл .git в каталог репо
    • переместите файл .gitignore в каталог репо
    • chdir в каталог репо
    • создайте песочницу mks внутри репо-сервера через "si creationandbox -P MKS_PROJECT_PATH --yes --projectRevision = CURRENTREV
    • введите описание ревизии через "si viewprojecthistory --rfilter = range: CURRENTREV-CURRENTREV", вывести вывод!
    • извлечь пользователя, дату, метку (метки), комментарии из предыдущего вывода
    • "git добавить."
    • pipe извлекает информацию сверху в "git commit -qF -" (не могу сделать -m, если вы хотите несколько строк, например, комментарий контрольной точки)
    • удалить песочницу через "si dropsandbox --yes index.pj"
    • переместите .git и .gitignore в место сохранения (для следующей итерации)
    • удалить все оставшиеся файлы в изолированной папке
    • перейдите в родительский каталог (..)
    • удалить песочницу/репо dir
  • создать окончательный git dir
  • переместите .git и .gitignore в финал git dir
  • "git reset --hard HEAD"

Готово.

MKS использует некоторую кодировку ASCII для своей строки, а git обычно использует UTF-8, поэтому следите за проблемой при импорте метаданных в git (имена пользователей, комментарии, теги и т.д.).

Для большего количества ветвей выполните следующее:

  • в каталоге git проверить версию, в которой должна начаться ветка, и создать ветку ( "git checkout -b NEWBRANCHNAME" )
  • теперь переместите .git и .gitignore в место сохранения и удалите весь каталог
  • теперь делают то же, что и выше.

Еще одна вещь: "si" - это инструмент командной строки MKS. Таким образом, вам нужно либо указать свой полный путь, либо указать путь к пути поиска.

Ответ 3

FWIW, si diff, к сожалению, в настоящее время не поддерживает унифицированный diff. Существует запрос на изменение, чтобы он это сделал, но пока еще слишком много клиентов, запрашивающих эту функцию.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я работаю в PTC (кто приобрел MKS).

Ответ 4

Это работает для контрольных точек...

https://gist.github.com/2369049

К сожалению, контрольные точки кажутся единственной вещью, которая действительно имеет смысл с MKS → GIT, поскольку контрольная точка действительно самая близкая к "снимку", который GIT вызывает фиксацию.

В MKS есть так много несовместимых понятий (для отслеживания версий файлов, ветвей, которые не похожи на ветки w92, контрольные точки и т.д.), которые могут эволюционировать независимо друг от друга, действительно сложно сказать, как перенести разумную историю в GIT. Вероятно, есть много способов сделать это, и ни один из них не будет более "правильным", чем следующий.

Тем не менее, я бы хотел услышать хорошие идеи.:)

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

Ответ 5

Я использую этот инструмент для импорта пакетов изменений из MKS в Mercurial, импорт его в git должен быть очень похожим; или вы можете сначала импортировать в Mercurial, а затем использовать инструмент git для импорта Mercurial.

https://github.com/arsane/py-mks2hg.git

Он попытается найти все пакеты изменений в рамках указанного проекта и выполнить заказ в новом хранилище Mercurial по порядку.