Czy można zaimportować repozytorium Integralności MKS do git?

Question

Potrzebuję tylko drzewa źródłowego i jego historii. Na razie nie dbam o wymagania/problemy. Grałem trochę z wierszem poleceń, aby dowiedzieć się, czy mogę uzyskać listę pakietów zmian dla pnia i niektórych ścieżek dev. Pomyślałem, że powinno być możliwe wyodrębnienie diff dla każdego pakietu zmian i użycie go do odtworzenia wszystkich zmian od czasu pierwszego zatwierdzenia w git. Coś takiego:

1. się najpierw zobowiązać i dodać go do git
2. dostać następną CP
3. dostać diff dla CP
4. stosować diff do git pracy dir
5. dodatek i zatwierdzić zmiany do git
6. Powtórz z (2.) do ostatniego CP

Możesz również zmienić pakiet za pomocą c heckpoint (byłoby wystarczająco dobre dla mnie).

Prostszym sposobem byłoby po prostu wykupienie CP i dodanie/zatwierdzenie do git. Ale wtedy tracisz możliwość dodawania, usuwania, przenoszenia i zmieniania nazw operacji.

Czy ktoś wie, jak uzyskać ujednolicone porównanie z "si diff"? To by już bardzo pomogło.

Wszelkie pomysły?

Edit2:
dodano odpowiedź, która pokazuje, jak ja faktycznie migracji ...

Answer 1

Problem z MKS Integrity jest ich wyjątkowa repozytorium, w którym wszystko przebywa:

• wymagania ,
• plany testów,
• przypadki testowe,
• cechy
• Zadania Programista,
• rozmieszczenie zażąda

Od tych danych może ewoluować niezależnie od siebie, w swoim własnym tempie, importując je wszystkie w jednym repozytorium Git byłoby złym pomysłem: możesz jedynie klonować zawartość repozytorium Git (nawet jeśli możesz ograniczyć głębokość tego klona).
To oznacza, że ​​otrzymasz wszystkie dokumenty, mimo że interesujesz się tylko kodem.
Eksportowanie integralności MKS oznaczałoby zdefiniowanie pierwszych wielu repozytoriów Git do działania jako submodules.

---

Muszę tylko drzewa źródłowego i jego historii.

Jak zwykle, polecam tylko importowanie:

• główne etykiet (na cokolwiek starszych niż rok, lub cokolwiek okres czujesz się komfortowo, że nie będą potrzebne zbadać w całości, ponieważ jest tak stare)
• wszystkie etykiety (główne i nieletnie) z ostatnich lat.

I nie byłoby importować wszystko w jeden Git repozytorium, chyba że jesteś pewien, że wszystkie źródła reprezentuje układ jeden opracowany jako wszystkich (a nie kilka „modułów” opracowane niezależnie)

Prostszym sposobem byłoby po prostu wykupienie CP i dodanie/zatwierdzenie do git.

To byłby sposób postępowania.

Ale wtedy straciłbyś możliwość dodawania, usuwania, przenoszenia i zmiany nazwy operacji.

Nie! Nie byłbyś! Git będzie infer those operations. Jest to zaletą bycia plikiem Content VCS.

Answer 2

Nie mogę opublikować aktualnego programu, który napisałem, ponieważ nie zrobiłem tego we własnym czasie. Mogę jednak opublikować, jak to zrobiłem. Powinno być łatwe powtórzenie go za pomocą dowolnego języka skryptowego. Narzędzie, które napisałem, przenosiło tylko jedną gałąź naraz. Powiedziałbym, która gałąź chcę (np. 1.21.1), a początkowa i końcowa wersja w oddziale (np. 4 i 78 będą migrować wszystkie wersje począwszy od 1.21.1.4 do 1.21.1.78). Aby mieć wszystkie gałęzie w jednym repo, udostępniłbym katalog .git do importowania do.

• rozpocząć pętlę od rozpoczęcia do zakończenia rewizji rewizji
  • Currentrev = BRANCH.loopcounter
  • utworzyć katalog Repo
  • Przesuń .git dir do katalogu repo
  • przenieść plik .gitignore do katalogu repo
  • chdir do katalogu repo
  • Utwórz piaskownicę mks wewnątrz repo dir v ia "si createsandbox -P MKS_PROJECT_PATH --yes --projectRevision = CURRENTREV
  • pobierz opis rewizji przez" si viewprojecthistory --rfilter = range: CURRENTREV-CURRENTREV ", przechwyć wyjście!
  • wyodrębnij użytkownika, datę, etykietę, komentarze z poprzedniego wyjścia
  • "git add."
  • rura ekstrakcji informacji z góry na "git commit -qF -" (nie można zrobić -m jeśli chcesz wiele linii jak komentarzu punktu kontrolnego)
  • spadek piaskownicy via "Si dropsandbox --yes index.pj"
  • przenieś .git i.gitignore do miejsca zapisu (dla następnej iteracji)
  • usunąć wszystkie pozostałe pliki w katalogu piaskownicy
  • Przejście do katalogu nadrzędnego (..)
  • kasowania sandbox/repo reż
• utworzyć ostateczną git dir
• ruch .git i .gitignore w final git reż
• "git zresetować --hard głowie"

do ne.

MKS używa pewnego rodzaju kodowania ASCII dla jego ciągu, a git zwykle używa UTF-8, więc uważaj na problem podczas importowania danych meta do git (nazwy użytkowników, komentarze, tagi itp.).

Więcej oddziałów to zrobić:

• w kasie katalogu git rewizji gdzie oddział powinien rozpocząć i utworzyć oddział ("git checkout -b NEWBRANCHNAME")
• teraz przenieść .git i. gitignore do zaoszczędzić miejsce i usunąć cały dir
• teraz zrobić to samo, co powyżej

jeszcze jedno: „si” jest narzędziem wiersza poleceń MKS. Musisz więc podać pełną ścieżkę lub umieścić ścieżkę w ścieżce wyszukiwania.

Answer 3

Działa to na przejściach ...

https://gist.github.com/2369049

Niestety, punkty kontrolne są pozornie jedyną rzeczą, która naprawdę ma jakiś sens z MKS -> GIT, jako punkt kontrolny jest naprawdę najbliższa rzecz do " snapshot ", który GIT wywołuje commit.

MKS ma tyle niekompatybilnych pojęć (śledzenie wersji plików, gałęzie, które nie przypominają gałęzi GIT, punktów kontrolnych itp.), Które mogą ewoluować niezależnie od siebie, ciężko powiedzieć, jak przenieść sensowną historię w GIT. Prawdopodobnie istnieje wiele sposobów na to, a żaden z nich nie jest bardziej "poprawny" niż następny.

To powiedziawszy, chciałbym usłyszeć dobre pomysły. :)

Chciałbym zobaczyć rozwiązanie, które przechwytuje wersjonowanie pliku w sensowny sposób. W niektórych dyskusjach zastanawialiśmy się, w jaki sposób próbować wyrównywać MKS-owe wersje per-file przez commit-time lub coś podobnego. W ten sposób możemy sformułować koncepcję "repo" ewoluującą poprzez zatwierdzenie, które zawiera zmiany w wielu plikach.

Answer 4

FWIW, si diff niestety nie obsługuje obecnie zunifikowanych różnic. Istnieje prośba o zmianę, aby to zrobić, ale nie było jeszcze zbyt wielu klientów pytających o tę funkcję.

OŚWIADCZENIE: Pracuję dla PTC (który nabył MKS).

Answer 5

Używam tego narzędzia do importowania pakietów zmian z MKS do Mercurial, import do git powinien być całkiem podobny; lub możesz najpierw zaimportować do Mercurial i użyć narzędzia git, aby zaimportować Mercurial.

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

będzie starał się znaleźć wszystkie pakiety zmian, które w ramach określonego projektu, i zobowiązać się do nowego repozytorium Mercurial w porządku.