J'ai besoin que de l'arborescence source et de son histoire. Je m'en fiche des exigences / problèmes des problèmes pour l'instant. J'ai joué un peu avec la ligne de commande pour déterminer si je pouvais obtenir une liste de packages de changement pour le coffre et certains des chemins de développement. Je pensais qu'il devrait être possible d'extraire une diff pour chaque changement de changement et d'utiliser cela pour rejouer tous les changements depuis la première commission de GIT. Quelque chose comme ça:
Vous pouvez également remplacer le paquet de changement avec le point de contrôle (serait suffisamment bon pour moi).
Un moyen plus simple serait de simplement céder un CP et d'ajouter / s'engager à gater. Mais alors vous perdriez une trace d'ajouter, supprimer, déplacer et renommer des opérations.
Est-ce que quelqu'un sait-il comment obtenir un differ unifié de "Si DIFF"? Cela aiderait déjà beaucoup.
Des idées?
A ajouté une réponse qui montre comment je faisais réellement la migration ...
5 Réponses :
Le problème avec MKS Integrity est leur référentiel unique dans lequel tout réside:
Étant donné que ces données peuvent évoluer indépendamment une d'une autre, à leur rythme, les importer dans un seul référentiel git serait une mauvaise idée: vous ne pouvez que cloner tous le contenu d'un repo ( Même si vous pouvez limiter la profondeur de ce clone). J'ai besoin que de l'arbre source et de son histoire.
Comme d'habitude, je ne recommanderais que l'importation:
Et je n'importerais pas tout dans le référentiel Git un sauf si vous êtes confiant que toutes vos sources représentent un système développé en tant que tout (et pas plusieurs "modules" développés indépendamment)
Un moyen plus simple serait de simplement céder un CP et d'ajouter / s'engager à gater.
Ce serait la voie à suivre.
Mais alors vous perdrez une trace d'ajouter, supprimer, déplacer et renommer des opérations.
Non! Vous ne voudriez pas! Git va infère ces opérations .
Cela signifie que vous obtiendrez tous les documents, même si vous êtes juste intéressé par le code.
Une exportation d'intégrité MKS impliquerait de définir d'abord de nombreux référentiels Git pour servir de Sumouules . < / p>
C'est l'avantage d'être un fichier > contenu VCS .
Je n'aurais besoin que de l'arbre source et de son histoire. Je m'en fiche des problèmes / objets / flux de travail. Peut-être que je devrais prolonger la question ...
Je continue à oublier que Git reconnaîtra renommé, etc. Mon modèle mental est toujours trop influencé par CVS, SVN et MKS. Merci, je vais essayer maintenant. Il y a environ 3 ans d'histoire et je pense que je recevrai tous les points de contrôle sur le tronc (60 ou 70) et que les dernières branches que sont réellement courtes. Peut-être que je peux même l'automatiser un peu avec les outils de ligne de commande SI.
Il suffit d'importer 62 points de contrôle de MKS dans Git avec un petit programme rapide et sale. C'était un peu délicat d'extraire les moments de validation, les étiquettes du point de contrôle et les commentaires, mais cela en valait la peine. Demain, je vais essayer un autre projet avec des branches plus grandes. Merci...
Question intéressante (et réponse). L'inférence de renommée est une caractéristique que je n'avais pas entendue. Intéressant. Peut-être que c'est temps pour moi de passer de SVN à git (à la maison - au travail, c'est MKS!).
Je ne peux pas poster le programme réel que j'ai écrit, car je ne l'ai pas fait à mon moment. Cependant, je peux poster comment je l'ai fait. Il devrait être facile de le refaire avec n'importe quel langage de script. L'outil que j'ai écrit n'a émigré qu'une seule branche à la fois. Je le dirais quelle branche je veux (par exemple 1.21.1) et la révision de départ et de fin de la succursale (par exemple 4 et 78 migrerait toutes les révisions à partir de 1.21.1.4 jusqu'à 1.21.1.78). Pour avoir toutes les branches d'un seul repo, je fournirais le répertoire .git à utiliser pour importer.
fait.
MKS utilise une sorte de codage ASCII pour sa chaîne et GIT utilise généralement UTF-8, ce qui montre un problème lors de l'importation de métadonnées dans GIT (noms d'utilisateur, commentaires, tags, etc.).
Pour plus de branches, faites ceci:
Une dernière chose: "Si" est l'outil de ligne de commande MKS. Vous devez donc spécifier son chemin complet ou mettre son chemin dans la trajectoire de recherche.
Cela fonctionne pour les points de contrôle ...
https://gist.github.com/2369049
Malheureusement, les points de contrôle sont apparemment la seule chose qui donne un sens de MKS -> Git, comme un point de contrôle est vraiment la plus proche du «Snapshot» que Git appelle un commit.
MKS a tellement de concepts incompatibles (suivi de la version de fichier, des branches qui ne ressemblent rien à des branches de git, de points de contrôle, etc.) qui peuvent tous évoluer de manière indépendante les uns des autres, il est vraiment difficile de savoir comment migrer une histoire sensible en git . Il y a probablement de nombreuses façons de le faire et aucun d'entre eux plus "correct" que le suivant.
Cela dit, j'aimerais entendre de bonnes idées. :)
J'adorerais voir une solution qui capture la version par fichier de manière raisonnable. Dans certaines discussions, nous avons jeté une idée de l'idée d'essayer de mettre en place des versions MKS Per-File en un degré de commettre ou de quelque chose. De cette façon, nous pouvons formuler le concept de «repo» évoluant par un commit qui contient des modifications de plusieurs fichiers.
FWIW, si diffus ne supporte pas actuellement de diff. Il y a une demande de changement pour le faire, mais il n'a pas encore été trop de clients demandant cette fonctionnalité.
Disclaimer: Je travaille pour PTC (qui a acquis MKS).
Où demandons-nous de telles fonctionnalités?
J'utilise cet outil pour importer des packages de modification de MKS dans Mercurial, l'importer sur Git devrait être assez similaire; Ou vous pouvez importer en premier à Mercurial et utiliser l'outil Git pour importer mercuriale suivant.
https://github.com/arsane/py-mks2hg.git < / p>
Il essaiera de trouver tous les packages de modification qui sous le projet spécifié et s'engagent dans un nouveau référentiel mercuriel dans l'ordre.
Je suppose que vous êtes fatigué de devoir voir / comprendre des choses comme "la révision 1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.3.1.1.1" Chaque fois que quelqu'un fusionne un package de changement? Bonne chance sur votre évasion de MKS.
C'est plus que ça. Si quelqu'un pense que leur SCM est lent, ils n'ont pas essayé MKS. J'aime les exigences / l'intégration de suivi des défauts, mais la source est aussi mauvaise que possible ...
Je viens de terminer ma réponse avec une procédure d'importation proposée en réponse à votre commentaire.
Merci pour votre retour. Peut-être d'autres utilisateurs MKS bénéficieraient de votre programme (même un "rapide et sale")? Vous pouvez l'ajouter comme une réponse à ce fil.
Je vais. Je veux le prolonger un peu, parce que j'en ai besoin pour des cas plus compliqués ...