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

Question

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

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

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

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

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

Есть идеи?

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

Answer 1

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

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

Готово.

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

Для дополнительных веток сделайте это:

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

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

Answer 2

Проблема с MKS Integrity заключается в их уникальном хранилище, в котором находится все :

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

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

---

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

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

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

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

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

Это был бы способ продолжить.

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

Нет! Ты бы не! Git будет выводить эти операции .
Это преимущество того, что файл Содержимое VCS .

Answer 3

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

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

Answer 4

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

https://gist.github.com/2369049

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

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

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

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

Answer 5

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

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

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