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

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

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

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

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

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

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

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

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

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

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

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

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

• begin loop from starting revision to ending revision
  • CURRENTREV=BRANCH.loopcounter
  • создать каталог репо
  • переместите каталог .git в каталог репо
  • переместите файл .gitignore в каталог репо
  • chdir в каталог репо
  • создайте песочницу mks внутри каталога репо через «si createandbox -P MKS_PROJECT_PATH --yes --projectRevision=CURRENTREV
  • получить описание версии через "si viewprojecthistory --rfilter=range:CURRENTREV-CURRENTREV", захватить вывод!
  • извлечь пользователя, дату, ярлыки, комментарии из предыдущего вывода
  • "Гит добавить."
  • передать извлеченную информацию сверху в «git commit -qF -» (невозможно сделать -m, если вы хотите несколько строк, таких как комментарий контрольной точки)
  • удалить песочницу через «si dropandbox --yes index.pj»
  • переместите .git и .gitignore в место сохранения (для следующей итерации)
  • удалить все оставшиеся файлы в каталоге песочницы
  • перейти в родительский каталог (..)
  • удалить папку песочницы/репозитория
• создать окончательный каталог git
• переместите .git и .gitignore в конечный каталог git
• "git reset --hard HEAD"

Готово.

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

Для большего количества ветвей сделайте это:

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

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

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

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

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

https://gist.github.com/2369049

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

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

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

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

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

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

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