Est-il possible d'importer un référentiel d'intégrité MKS dans git?

Question

J'ai besoin que l'arbre source et son histoire. Je ne me soucie pas pour les choses exigences / problèmes pour l'instant. J'ai joué un peu witth la ligne de commande pour comprendre si je pouvais obtenir une liste des paquets de changement pour le tronc et quelques-uns des chemins dev. Je pensais qu'il devrait être possible d'extraire un diff pour chaque paquet de changement et de l'utiliser pour rejouer tous les changements depuis la première livraison en git. Quelque chose comme ceci:

1. get premier commit et l'ajouter à git
2. get suivant CP
3. get diff pour CP
4. appliquer diff git travail dir
5. ajouter et valider les modifications à git
6. répétition avec (2) jusqu'à ce que dernier CP

Vous pouvez également paquet changement repleace avec point de contrôle (serait assez bon pour moi).

Une façon plus simple serait à la caisse juste un CP et ajouter / engager à git. Mais alors vous perdre la trace de ajouter, supprimer, déplacer et renommer des opérations.

Quelqu'un sait comment obtenir un diff unifié de « si diff »? Ce serait déjà beaucoup aider.

Toutes les idées?

Edit2: Ajout d'une réponse qui montre comment je fait réellement la migration ...

Answer 1

Le problème avec MKS Integrity est leur référentiel unique dans lequel tout Résidence:

• exigences,
• plans de test,
• cas de test,
• caractéristiques,
• tâches de développement,
• demandes de déploiement

Étant donné que ces données peuvent évoluer indépendamment les uns des autres, à leur propre rythme, de les importer en un seul dépôt Git serait une mauvaise idée: vous pouvez seulement clone tous le contenu d'un repo Git ( même si vous pouvez limiter la profondeur de ce clone).
Cela signifie, vous obtiendrez tous les documents, même si vous êtes simplement intéressé par le code.
Une exportation MKS Integrity impliquerait de définir plusieurs premiers référentiels Git pour agir en tant que sous-modules.

---

  

J'ai besoin que l'arbre source et son histoire.

Comme d'habitude, je recommande que l'importation:

• les grandes maisons de disques (pour quoi que ce soit plus d'un an, ou quelle que soit la période que vous sentez à l'aise vous pas besoin de l'examiner en entier, car il est si vieux)
• toutes les étiquettes (principaux et mineurs) pour les dernières années.

Et je n'importer tous dans un dépôt Git à moins que vous êtes sûr que toutes vos sources représente un système développé en tant que tous (et non plusieurs « modules » développés indépendamment)

  

Une façon plus simple serait à la caisse juste un CP et ajouter / engager à git.

Ce serait la façon de procéder.

  

Mais alors vous perdre de piste ajouter, supprimer, déplacer et renommer des opérations.

Non! Vous ne voudriez pas! Git déduisent ces opérations .
C'est l'avantage d'être un fichier contenu VCS .

Answer 2

Je ne peux pas poster le programme réel je l'ai écrit, parce que je ne le fais pas mon temps. Cependant, je peux poster comment je l'ai fait. Il devrait être facile de le refaire avec tout langage de script. L'outil que j'ai écrit migré une seule branche à la fois. Je lui dire quelle branche je veux (par exemple 1.21.1) et le début et la fin de révision dans la branche (par exemple 4 et 78 changeraient toutes les révisions à partir de 1.21.1.4 jusqu'à 1.21.1.78). Pour avoir toutes les branches dans un repo je fournirais le répertoire .git à utiliser pour importer dans.

boucle
• commencer la révision de commencer à mettre fin à la révision
  • Currentrev = BRANCH.loopcounter
  • créer le répertoire repo
  • déplacer le répertoire .git dans le répertoire repo
  • déplacer le fichier dans le répertoire .gitignore repo
  • chdir dans le répertoire repo
  • créer bac à sable MKS à l'intérieur du répertoire repo via « si createsandbox -P MKS_PROJECT_PATH --yes --projectRevision = Currentrev
  • fetch Description de révision par "si viewprojecthistory --rfilter = gamme: Currentrev-Currentrev"!, Sortie de capture
  • utilisateur extrait, la date, l'étiquette (s), les commentaires de la sortie précédente
  • "git add."
  • tube information extraite par le haut dans « git commit -qf - » (ne peut pas faire -m si vous voulez plusieurs lignes comme le commentaire de checkpoint)
  • bac à sable goutte via "si dropsandbox --yes index.pj"
  • déplacer .git et .gitignore à un endroit de sauvegarde (pour l'itération suivante)
  • supprimer tous les fichiers restants dans le répertoire bac à sable
  • move dir parent (..)
  • supprimer bac à sable / dir repo
• créer dir git finale
• move .git et .gitignore en dir git finale
• "git reset HEAD --hard"

Fait.

MKS utilise une sorte de codage ASCII pour sa chaîne et git utilise généralement UTF-8 montre donc pour problème lors de l'importation des métadonnées dans git (noms d'utilisateurs, commentaires, tags, etc.).

Pour plus de branches font ceci:

• dans la caisse de répertoire git la révision où la branche devrait commencer et créer une branche ( « caisse git -b NEWBRANCHNAME »)
• allons maintenant passer .git et .gitignore à la sauvegarde place et supprimer tout le répertoire
• maintenant faire la même chose que ci-dessus

Une autre chose: « si » est l'outil de ligne de commande MKS. Donc, soit vous devez spécifier le chemin complet ou mettre son chemin dans le chemin de recherche.

Answer 3

FWIW, si diff ne malheureusement pas encore unifié diff prennent en charge. Il y a une demande de changement de l'avoir le faire, mais il n'y a pas encore trop de clients demandant cette fonctionnalité.

DISCLAIMER:. Je travaille pour PTC (qui a acquis MKS)

Answer 4

Cela fonctionne pour les postes de contrôle ...

https://gist.github.com/2369049

Malheureusement, les points de contrôle sont apparemment la seule chose qui fait vraiment aucun sens de MKS -> GIT, comme un point de contrôle est vraiment la chose la plus proche du « instantané » qui GIT appelle une validation.

MKS a tant de concepts incompatibles (par le suivi des versions de fichiers, branches qui ne sont rien comme les branches de GIT, postes de contrôle, etc.) qui peuvent tous évoluer indépendamment les uns des autres, il est vraiment difficile de dire comment migrer une histoire sensible en GIT . Il y a probablement plusieurs façons de le faire et aucun d'entre eux plus « correcte » que les autres.

Cela dit, j'aimerais entendre quelques bonnes idées. :)

J'aimerais voir une solution qui capture le versioning par fichier d'une manière sensible. Dans certaines discussions que nous avons jeté autour de l'idée d'essayer d'aligner MKS versions par fichier par commit-temps ou quelque chose. De cette façon, nous pouvons formuler le concept de l'évolution « repo » par un commit qui contient des changements dans plusieurs fichiers.

Answer 5

J'utilise cet outil pour importer des packages de changement de MKS dans Mercurial, importer à git devrait être assez similaire; ou vous pouvez importer Mercurial d'abord, et utiliser l'outil git pour importer Mercurial suivant.

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

Il va essayer de trouver tous les packages de modifications que dans le cadre du projet spécifié et engagent à nouveau référentiel Mercurial dans l'ordre.