Metoda integracji różnych systemów kontroli wersji lub wybranie jednego spośród innych z powodu fuzji i przejęć?

Firmy przejmują inne firmy, które korzystają z różnych systemów kontroli wersji.

Czy istnieje powszechna wiedza na temat integracji takich systemów razem, na przykład przy użyciu mostu Subverson-GIT lub nawet decydowania o użyciu tylko jednego narzędzia nad drugim - i jak migrować między systemami?

Czy ludzie używają zestawu kryteriów przy podejmowaniu takich decyzji, na przykład odpowiednika testu „Joela” dotyczącego tworzenia oprogramowania?

Aby odpowiedzieć na pytanie dotyczące migracji z własnego doświadczenia kilku migracji:

Nie obawiaj się po prostu umieścić aktualną wersję oprogramowania w nowym systemie kontroli źródła jako linię bazową i pracować od tego momentu.

Zdecydowana większość czasu nie będziesz potrzebować historii. Oznacza to, że jest o jedno zadanie mniej do wykonania podczas integracji, a jedno jest mniej do popełnienia.

Aktywnie rozwijane pliki / projekty wkrótce wygenerują nową historię. Kiedy więc musisz dowiedzieć się, dlaczego dokonano zmiany, istnieje szansa, że ​​historia znajdzie się w bieżącym repozytorium, ponieważ będzie to ostatnia zmiana.

Pliki / projekty, które były stabilne przed migracją powinny (wszystkie rzeczy są równe) pozostać stabilne po migracji, więc nie trzeba odwoływać się do historii. Odkryliśmy, że gdybyśmy musieli zbadać błąd w tak starym pliku / projekcie, posiadanie historii nie przyniosłoby żadnej korzyści. Tak długo, jak utrzymasz stare repozytorium dostępne przez 6 miesięcy / rok, będziesz mieć takie referencje w takich przypadkach.

Po stronie menedżerskiej chodzi głównie o:

• wsparcie : czy firma wypuszczająca VCS będzie nadal dostępna w przypadku problemów.
  Jest to niestety jeden z głównych powodów, dla których tak przestarzałe produkty, takie jak ClearCase, są nadal brane pod uwagę (ClearCase jest od 2003 roku ... produktem IBM )
• koszt licencji : nawet jeśli istnieją bezpłatne alternatywy, czasami „licencje grupowe” na VCS mogą być negocjowane lub faktycznie zawarte w znacznie większej umowie obejmującej serwery, sieci, wsparcie itp. ... Licencja globalna dla tego rodzaju produktu może się skończyć kosztują znacznie mniej niż cena publiczna.

Po stronie projektu chodzi również o:

• administracja : na którym serwerze zainstalujesz VCS (lub wiele VCS, jeśli mówimy o Git, SVN i innych)? Z jakimi zasadami tworzenia kopii zapasowych? Jaki DRP (Disasterry Recovery Plan)?
• wsparcie lokalne : kto weźmie wsparcie poziomu 1? poziom 2?
• znajomość rynku : czy na pewno znajdziesz wystarczającą liczbę programistów i / lub administratorów z odpowiednim zestawem wiedzy, aby wykorzystać ten VCS i wszystkie jego funkcje?

Darmowe lub nie, pamiętaj, że „darmowe” oprogramowanie jest bezpłatne, jak w „swobodnej mowie” (możesz wybrać i wdrożyć to, co chcesz), a nie jak w „darmowym piwie” (nadal będzie dużo kosztować na serwerze , tworzenie kopii zapasowych, administracja, wsparcie, ...)

Wymienione powyżej kryteria są początkiem ustalenia, co VCS zatrzymać, a co zrezygnować.
Ale w tym drugim przypadku należy wziąć pod uwagę:

• strategia migracji : czy możesz eksportować / importować historię projektu z jednego VCS do drugiego?
• strategia pomostowa : czy warto mieć historię w dwóch różnych systemach VCS?
• przestarzałość projektu : jeśli projekt jest w stanie konserwacji / zakończenia życia, lepiej może obsługiwać stary VCS przez krótki czas.

Czy naprawdę potrzebujesz integracji różnych systemów? W naszym zespole każdy projekt żyje we własnym repozytorium, a ich historia jest niezależna. Nie mamy tutaj problemu do pracy z niektórymi projektami podwersjonowanymi, a innymi pod merkurialem, nawet jeśli istnieją między nimi zależności.

Jeśli zdecydujesz się na migrację z jednego VCS do drugiego, sprawdź dostępne narzędzia do konwersji. Z mojego doświadczenia nie wynika żaden techniczny powód, aby porzucić historie projektów.

Edytować

Myślę, że zrozumiałem coś, co było ukryte w pytaniu i innych odpowiedziach. Faktem jest, że VCS są również używane do zarządzania zależnościami. Wiem, że dość często używa się funkcji VCS, takich jak svn:externalsintegracja jednego repozytorium (zależności) z innym.

Myślę, że (technicznym) powodem, dla którego nasz zespół nie odczuwa potrzeby połączenia (lub integracji) naszych 2 różnych systemów, jest to, że mamy oddzielne narzędzie do zarządzania zależnościami. Nasze repo nie znają się.

Wiele dobrych odpowiedzi. Inną rzeczą do przemyślenia jest to, że nie pozwól członkom zespołu myśleć, że zmiana VC to tak wielka sprawa. Nastąpi niepowodzenie związane z migracją, krzywą uczenia się itp., Ale jeśli mają zbyt wiele problemów, muszą zakwestionować swój poziom umiejętności i / lub współpracy.