Od jakiegoś czasu na listach PLD toczy się dyskusja na temat zmiany układu repozytorium. mmazur ogłosił niedawno testowe wdrożenie układu podobnego do używanego przez Portage. Mam nadzieję, że to pierwszy krok na drodze do zmiany samego systemu wersjonowania kodu. A ma co śledzić, bo — wbrew pozorom — dystrybucja to dziesiątki tysięcy plików, nad którymi trzeba jakoś zapanować.
CVS
Obecnie do zarządzania repozytorium używamy CVS. Ma swoje wady i zalety. Przede wszystkim można w nim wiele rzeczy automatyzować, choćby ze względu na to, że pliki w repozytorium mają swoje przełożenie 1:1 na fizyczne pliki na dysku. Plik foo.spec ma wszystkie swoje dane w pliku foo.spec,v i można go sobie ręcznie backupować, edytować albo zmienić mu nazwę. No właśnie, CVS ma kilka wad:
- Nie ma możliwości przeniesienia czegokolwiek w repozytorium. Można usunąć plik i dodać go pod nową nazwą, ale w tym momencie tracimy jakąkolwiek historię. Jedyna opcja to fizyczna zmiana nazwy pliku kontroli wersji przez osobę z uprawnieniami administratora na serwerze.
- Gałęzie i tagi są przywiązane do poszczególnych plików kopiowanie, scalanie i przenoszenie plików pomiędzy gałęziami to prawdziwy wrzód na dupie.
- Z powyższego powodu, praca na kilku gałęziach jednocześnie jest bardzo męcząca. Każdą gałąź trzeba pobrać z repozytorium do osobnego katalogu. Każdy nowy plik odpowiednio oznaczyć, bo w przeciwym wypadku trafi w najmniej pożądane miejsce. Do tego musimy spierać się z serwerem o to, że wiemy, że plik o identycznej nazwie już istnieje na innej gałęzi, ale nie ma nic wspólnego z naszym.
- Nie istnieją zestawy zmian, każda zmiana w repozytorium jest pojedynczą operacją i nie ma po niej śladu w żadnym pliku poza aktualnie modyfikowanymi.
Mercurial
Świeżutka zabawka, łatwo rozwijalna, ale jeszcze nie spełnia oczekiwań dużej dystrybucji:
- Każda kopia robocza jest pełnym odbiciem lustrzanym głównego repozytorium. Nie ma możliwości pobrania jednego pliku, dokonania w nim zmian i wysłania z powrotem.
- Rozbicie na rewizje i kody zestawów zmian jest bardzo nieintuicyjne ze względu na fakt, że tylko kod szesnastkowy jest unikalny.
- Zaśmieca kopię roboczą, tworząc w niej katalogi z metadanymi, co utrudnia pracę z narządziami operującymi na plikach rekursywnie (
diff,find,grep).
GIT
Rozproszony system kontroli wersji zaprojektowany przez Linusa Torvaldsa. Nadawałby się świetnie, gdyby nie to, że ma intuicyjność składni zbliżoną do Emacsa. W związku z tym, nikt nie zmusi deweloperów, żeby z dnia na dzień nauczyli się nowego narzędzia i przepisali wszystkie swoje skrypty. Zwłaszcza, że z opcji pracy offline skorzysta góra kilka osób (w przypadku dystrybucji, ciężko bez dostępu do sieci zbudować jakikolwiek pakiet).
Subversion
Narzędzie sprawdzone, oferuje to samo, co CVS, jednocześnie poprawiając jego niedociągnięcia. Nie oferuje pracy na rozproszonych kopiach repozytorium. Ma za to jedną wadę Mercuriala:
- Zaśmieca kopię roboczą, tworząc w niej katalogi z metadanymi.
- Kod pobrany z repozytorium zajmuje dwa razy więcej miejsca niż powinien, bo trzymana jest lokalna kopia pliku (co pozwala na częściową pracę offline).
Subversion + SVK
Wyobraźcie sobie Subversion, ale bez wspomnianych problemów. Z pełnym wsparciem dla pracy offline. To właśnie jest SVK — pełni rolę klienta Subversion, zarządzając jednocześnie kopią roboczą i klonami repozytorium. Kopie robocze nie są wzbogacane o żadne magiczne katalogi z metadanymi, nie mają narzutu w postaci trzymania kopii plików, a do tego system potrafi śledzić lokalne scalenia i automatycznie podpowiada komentarz przy upychaniu swoich zmian z powrotem do głównego repozytorium Subversion.
Rozwiązanie niemal idealne — miłośnicy GIT mają swoje ulubione funkcje, a reszta może używać tradycyjnego klienta Subversion. Bez żadnej magii shellowej.
Review Board
A skoro już mowa o Subversion, to kilka dni temu chipX86 ogłosił projekt, który stworzyli wewnętrznie na potrzeby VMware. Review Board, bo tak się nazywa, to aplikacja Django, która pozwala wygodnie przechowywać nadsyłane łatki. Na listach PLD pojawia się ich sporo i często giną w czeluściach skrzynek pocztowych. Coś takiego z pewnością by nam się przydało — miejsce, gdzie każdy z uczestników listy może zaproponować swoje zmiany i otrzymać komentarze jeszcze przed włączeniem ich do samej dystrybucji. Miejsce, gdzie łatki nie giną.