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

Question

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

1. получить первую фиксацию и добавить его в мерзавец
2. получить следующий CP
3. получить дифференциал для CP
4. применять дифф мерзавца работать реж
5. надстройки и вносить изменения в мерзавец
6. повторить с (2) до последнего CP

Вы также можете repleace изменения пакета с с heckpoint (было бы достаточно для меня).

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

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

Любые идеи?

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

Answer 1

Проблема с MKS Integrity является их уникальное хранилище, в котором все проживает:

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

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

---

мне нужно только дерево источника и его истории.

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

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

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

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

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

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

Нет! Ты бы не! Git будет infer those operations.
То есть преимущество быть файлом Content VCS.

Answer 2

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

• начинают цикл от начала ревизии до окончания ревизии
  • CURRENTREV = BRANCH.loopcounter
  • создайте каталог Repo
  • Подведите .git реж в каталог репо
  • переместить файл .gitignore в каталог repo
  • chdir в каталог repo
  • создать mks песочницу внутри repo dir v ia "si creationandbox -P MKS_PROJECT_PATH --yes --projectRevision = CURRENTREV
  • введите описание ревизии через« si viewprojecthistory --rfilter = range: CURRENTREV-CURRENTREV », вывести вывод!
  • выписка пользователь, дата, ярлык (ы), комментарии с предыдущего выпуска
  • "git add."
  • труба извлекается информация сверху в «мерзавцем совершить -qf -» (не может сделать -m, если вы хотите использовать несколько строк, как проходную комментарий)
  • падение песочницы через «си dropsandbox --yes index.pj»
  • переместить .git и.gitignore к экономии места (для следующей итерации)
  • удалить все оставшиеся файлы в каталоге песочнице
  • перейти к родительскому директории (..)
  • дир удаления песочнице/репо
• создать окончательный GIT реж
• ход .git и .gitignore в окончательный мерзавца реж
• "мерзавец сброса --hard ГОЛОВУ"

Do северо-восток

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

Для более ответвлений это сделать:

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

еще одно: «си» является инструментом командной строки MKS. Поэтому вам нужно либо указать свой полный путь, либо поместить его путь в путь поиска.

Answer 3

Это работает для контрольно-пропускных пунктах ...

https://gist.github.com/2369049

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

В MKS есть так много несовместимых понятий (для отслеживания версий файлов, ветвей, которые не имеют ничего общего с ветвями GIT, контрольно-пропускными пунктами и т. Д.), Которые могут эволюционировать независимо друг от друга, действительно трудно сказать, как перенести разумную историю в ГИТ. Вероятно, есть много способов сделать это, и ни один из них не будет более «правильным», чем следующий.

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

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

Answer 4

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

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

Answer 5

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

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

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