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

StackOverflow https://stackoverflow.com/questions/1314218

Вопрос

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

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

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

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

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

Есть идеи?

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

Это было полезно?

Решение

Проблема с МКС Честность это их уникальный репозиторий, в котором все проживает:

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

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

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

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

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

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

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

Именно так и следует действовать.

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

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

Другие советы

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

  • начать цикл от начальной версии до конечной версии
    • CURRENTREV=BRANCH.loopcounter
    • создать каталог репо
    • переместите каталог .git в каталог репо
    • переместите файл .gitignore в каталог репо
    • chdir в каталог репо
    • создайте песочницу mks внутри каталога репо с помощью «si createandbox -P MKS_PROJECT_PATH --yes --projectRevision=CURRENTREV
    • получить описание версии через «si viewprojecthistory --rfilter=range:CURRENTREV-CURRENTREV», захватить выходные данные!
    • извлечь пользователя, дату, метки, комментарии из предыдущего вывода
    • "git добавить."
    • передать извлеченную информацию сверху в "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.Поэтому вам нужно либо указать его полный путь, либо указать его путь в пути поиска.

Кстати, 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.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top