2009-02-12 19 views
16

Rozważamy przejście z ClearCase do Subversion. Projekt istnieje już od jakiegoś czasu (7 lat) i istnieją trzy "główne" wersje (gałęzie), które aktywnie wspieramy, oraz niektóre okazjonalne poprawki w starszych wersjach. Projekt jest dość duży - około 2 milionów linii kodu Java.Jaka jest najlepsza strategia podczas migracji z ClearCase do SVN?

Jestem ciekawy, czy istnieje ktoś, kto przeprowadził podobną migrację.

  • Czy SVN będzie w stanie obsłużyć tak duży projekt?
  • Czy ma sens migracja wszystkich historycznych wersji/oddziałów? Czy narzędzia mogą to robić selektywnie?
  • Jak długo potrwa proces migracji dla takiego projektu i jaki jest skuteczny sposób pracy, to migracja jest w toku?
+0

Ja drugie pytanie. ;-) –

+0

krótkie pytanie. Windows? – Avram

Odpowiedz

9

o dokonanie kilku migracje tego rodzaju, będę argumentować, że:

  • nie trzeba importować wszystkie historii wersjach clearcase język SVN. Przez większość czasu (z mojego doświadczenia) potrzebne są tylko wersje oznaczone etykietą (ta, która jest konsekwentnie stosowana we wszystkich plikach danego zestawu), chyba że naprawdę potrzebujesz drobiazgowego egzaminu z historii.

  • trzeba myśleć o reorganizacja podczas migracji:? Co ty importować, co zostawić, a chcesz zawartość SVN odzwierciedlać dokładnie struktura plików przechowywanych w VOB ClearCase? Czasami takie migracje są okazją do przemyślenia niektórych z tych organizacji plików (zwykle poprzez proste reguły zmiany nazw dla niektórych katalogów).

  • migracja jest szybsza w ClearCase 2 SVN sposób, ponieważ SVN to repozytorium-centric i zobowiązać się zestaw plików, natomiast ClearCase jest file-centric i zobowiązuje plik po pliku (znacznie sloooower)

  • jeśli zbiór plików do zaimportowania jest wyraźnie zidentyfikowany, proces migracji może zostać powtórzony wiele razy, co oznacza, że ​​możesz kontynuować pracę w obrębie ClearCase podczas pierwszego (dużego) importu, a następnie umieścić linię bazową (etykietę UCM) na swoim kodzie i ponownie zaimportuj tylko deltę, skutecznie kończąc proces migracji.

1
  1. Tak, Subversion może obsłużyć bardzo duże projekty. Na przykład wszystkie Apache projects znajdują się w jednym repozytorium Subversion, a podprojekty są prostymi podfolderami.
  2. Jeśli ma sens konwersja całej historii, to musisz sam zdecydować. Ale jest mnóstwo dostępnych narzędzi. Dobry wpis na blogu można znaleźć here.
  3. Nie wiem, jak długo trwa taka konwersja. Ale możesz spróbować najpierw z małym podzbiorem i zmierzyć czas.
+0

Wbrew temu, co myślisz, Apache nie jest zbyt dużym projektem, to nawet nie jest duży projekt. Ma tylko około 30 współpracowników. Jest to średniej wielkości projekt. SVN nie jest w stanie obsługiwać dużych projektów. Rozmiar bazy kodowej nie jest tak naprawdę decydującym czynnikiem, jak liczba osób, które muszą współpracować, a także ilość interakcji, rozgałęziania i łączenia. –

+0

Zanim podejmiesz fałszywe założenia dotyczące rozmiaru projektu, zapoznaj się z repozytorium Apache (http://svn.apache.org/repos/asf/). Repozytorium obsługuje nie tylko projekt serwera WWW Apache, ale także * wszystkie * projekty Apache, wraz z setkami użytkowników. – Stefan

+0

Rozmiar podstawy kodu zwykle nie stanowi problemu dla żadnego systemu kontroli źródła. Z wyjątkiem może ClearCase, który w poprzednich wersjach miał limit 16 milionów obiektów na vob, co oznaczało jakąkolwiek wersję lub etykietę zastosowaną do dowolnej wersji. Potrzebowałeś kilkudziesięciu VOB do dużych projektów lub zacznij usuwać stare wersje. Nie jest to istotne dla tego konkretnego pytania, ale to, co mówisz o Apache, nadal nie czyni z niego dużego projektu, tylko duży kod. SVN doskonale radzi sobie z dużymi bazami kodu, po prostu niezbyt dużą liczbą autorów i złożonym procesem rozwoju. –

5

Pierwsze niektóre zasoby:

  1. Clearvision CC2SVN Tool
  2. SVN Importer by Polarion
  3. Article and resources on CollabNet

Wielkość rzeczywistego repozytorium, liczba plików i ich rozmiary nie są czynnikiem ograniczającym dla SVN. Liczba programistów, współbieżność zmian, złożoność procesu integracji i wydania, konieczność łączenia i wersjonowania katalogów (refaktoryzacja) może stanowić problem dla dużego projektu. Jeśli Twój projekt jest po prostu duży, ale jest dość stabilny, z małą liczbą programistów, niewielką liczbą oddziałów i bez potrzeby przenoszenia wielu poprawek do kilku wcześniejszych wersji, SVN powinien zrobić dobrze dla ciebie.

Napisałem niestandardowe narzędzie migracji danych z ClearCase i nie jest to łatwe zadanie. Co dwa systemy mają różne modele danych i operacje na danych. Nie sugerowałbym próby napisania żadnego niestandardowego narzędzia do migracji, ponieważ bardzo trudno jest uzyskać dane z ClearCase w jakikolwiek znaczący sposób. Aby poznać szczegóły na temat ograniczeń komercyjnych rozwiązań, sugerowałbym skontaktowanie się z dostawcami rozwiązań połączonymi zasobami.

Osobiście spróbuję zebrać jak najwięcej danych, ale musisz mieć świadomość ograniczeń SVN w porównaniu do ClearCase. Historia migracji katalogów (refaktoryzacja) prawdopodobnie zostanie utracona podczas tej migracji. SVN nie obsługuje rozrzedzonych gałęzi, takich jak ClearCase, które mogłyby zwiększyć rozmiar repozytorium SVN na wypadek użycia gałęzi zadaniowych. W takim przypadku prawdopodobnie chcesz ograniczyć się tylko do gałęzi systemu. Pliki w ClearCase mają osobną strukturę rozgałęzień, podczas gdy SVN ma gałęzie według jednego produktu, co spowoduje wiele translacji gałęzi w procesie. Ograniczając się do gałęzi systemu i być może tylko wersji etykietowanej na tych oddziałach w celu uzyskania w pełni zintegrowanych etykiet z serii, można zaoszczędzić sobie wielu kłopotów. Jeśli Twój zespół korzysta z UCM, możesz prawie zapomnieć o wszystkich metadanych UCM. Nie będą tłumaczone na SVN.

Ramy czasowe w dużej mierze zależą od użytych narzędzi. W przypadku dużego projektu takiego jak Ty może to być nawet kilka tygodni. Baza danych ClearCase ma z jakiegoś dziwnego powodu wiele blokad nawet przy operacjach czytania i istnieje jeden centralny zbiór wszystkiego, co stwarza wiele problemów w dostępie na dużą skalę, jak spowodowałaby migracja. Za pierwszym razem, gdy uruchomiłem moje narzędzie na produkcie nieco większym niż Twój, oszacowaliśmy, że będzie on działał przez 3 lata, po dużej optymalizacji, równoległości i migracji przyrostowej zmniejszył się do około tygodnia. Ale spodziewaj się, że w zależności od tego, jak dobrze narzędzie zostanie wykonane, może zaistnieć duże zróżnicowanie czasu. Chociaż od migracji do SVN i zignorujesz wiele historii i metadanych z ClearCase, twoja migracja powinna być znacznie szybsza.

ClearVision wspomina na swoich stronach, że narzędzie CC2SVN może utworzyć pomost między tymi dwoma produktami. Chociaż nie korzystałem z tego narzędzia, jeśli działa zgodnie z założeniem, umożliwiłoby to zsynchronizowanie 2 repozytoriów po pewnym przetworzeniu, co pozwoliłoby na kilka weekendowych zmian, z zerowym przestojem w rozwoju. Jeśli nie jest to możliwe, spytaj o jakąś alternatywę, jak migracja przyrostowa, gdzie po raz pierwszy migrujesz do pewnej daty, a następnie zmigruj mniejszą porcję danych zmienioną od tej daty.

Bardzo ważną częścią procesu jest faza po migracji. Nie należy lekceważyć bólów głowy, jakie zmiana ta przyniesie twoim programistom. Nie wolno lekceważyć potrzeby szkolenia i jasnej dokumentacji. Potrzebny będzie również wyszkolony zespół wsparcia w dziale inżynierii oprogramowania, który będzie w stanie obsługiwać oba systemy SCM i wyjaśnić programistom, jak robić rzeczy, do których byli przyzwyczajeni w nowym systemie.To jest rzeczywiście punkt, który może złamać twoją szyję podczas migracji. Deweloperzy opierają się wszelkim zmianom i zaletom, jakie SVN przynosi projektowi, jest to w istocie znacznie gorszy system. ClearCase zapewnia Twoim programistom tak dużą elastyczność, jakiej nigdy nie mieliby dzięki SVN i jeśli nie wprowadzisz ich na wczesnym etapie procesu, możesz stracić je lub, co gorsza, cofnąć całą migrację, zadeklarować katastrofę i stracić własną pracę.

1

Inną opcją jest Migrate2SVN. Programista (Clearvision) właśnie wydał wersję 2.0 i wygląda na to, że zawiera wiele WIELE ulepszeń w stosunku do oprogramowania Polarion i inne metody wspomniane powyżej.

Powiązane problemy