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?
Odpowiedzi:
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:
Po stronie projektu chodzi również o:
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ę:
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.
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.