Niejednokrotnie pisałem o SVN, zachwycając się cudownością tego narzędzia. Wpłynęło ono na moje życie zawodowe dość znacząco – tak naprawdę od niego zacząłem przygodę z kontrolą wersji. A kontrola wersji całkowicie zmienia sposób pracy, o czym przekonał się każdy kto zaczął korzystać z jakiegokolwiek systemu z tej rodziny. Subversion było też standardem w tej dziedzinie, dzielnie wypierając znienawidzonego przez wielu Visual Source Safe.
Ale jak to się mawia: życie to nie je bajka. Sentyment sentymentem, ale gdy coś zaczyna zawodzić, trzeba znaleźć alternatywę. I mówiąc krótko: ponad pół roku temu SVN okazało się narzędziem tak irytującym, że musiał nastąpić przewrót w największym projekcie przy którym pracuję. SVN to już przeszłość.
Problemy z SVN per se
Jak wpakować się w kłopoty przy pomocy Subversion? Jest to bardzo proste: wystarczy skorzystać z funkcji branch. Tworzenie gałęzi jest tak podstawową funkcjonalnością systemu kontroli wersji, że nie powinno sprawiać żadnych problemów w użytkowaniu. I przekornie można powiedzieć: OK, ale przecież w SVN stworzenie gałęzi jest szybkie, wydajne i banalnie proste! I… zgadza się. Ale pogadamy, gdy po branch spróbujesz wykonać merge (bez którego branch jest przecież bezużyteczny).
Dla uściślenia wspomnę, że nie jestem “nieświadomym swoich czynów” głupim użytkownikiem. Poświęciłem sporo czasu na poznanie funkcjonalności SVN, przeczytałem książkę o tym narzędziu. Starałem się ROZUMIEĆ co się dzieje z moim kodem na każdym etapie jego życia w repozytorium. Nie klikam na oślep “next -> ok -> next” w nadziei, że wszystko będzie dobrze. Dlaczego więc SVN najzwyczajniej w świecie nie działa mi tak jak trzeba gdy tylko wyjdę poza jednoosobowe korzystanie z repozytorium ograniczające się do komend “checkout / update / commit / tag / log”? Równie dobrze mogę sobie robić co pół godziny zipa i wykonywać jego backup…
Próba skorzystania z tzw. “zaawansowanych” funkcji (zagłębione rozgałęzianie, mergowanie, usuwanie/dodawanie/zmiana nazwy plików i katalogów) kończyła się niejednokrotnie całkowitym rozjechaniem mojej lokalnej working copy. Ileż to razy w ciągu kilku miesięcy musiałem ciągnąć z repozytorium całkowicie świeży kod tylko dlatego, że SVN nie potrafił wysłać moich zmian na serwer bądź pobrać z owego serwera nowej wersji! A jak w środku dnia pracy przychodzi pociągnąć z sieci te 300-400MB za pomocą Tortoise a potem ręcznie przenosić wykonane zmiany do nowej kopii to człowieka naprawdę szlag może trafić i krew zalać (nawet samca).
Dosyć mam już komunikatu mówiącego, żebym wykonał komendę Clean Up (bez podania przyczyny, która czasami COŚ naprawia a czasami nie). Dosyć mam błędów Tree conflict. Spędziłem masę czasu na rozwiązywaniu takich problemów, które powinny być rozwiązane za mnie!
Ale to jeszcze nic! Dwa razy przydarzyła mi się sytuacja tak bardzo karygodna, że aż strach. Miało to miejsce w moim domowym repozytorium w konfiguracji: host (win xp / win 7) jako serwer SVN oraz wirtualna maszyna (win 2003) jako klient. Po swobodnym baraszkowaniu z kodem po stronie klienta i pchnięciu zmian (zakończonym błędem z niewiadomego powodu) repozytorium stało się… niezdatne do użytku! Potrafię zrozumieć nieudany commit (chociaż chciałbym dowiedzieć się DLACZEGO się nie udał), ale zepsucie repozytorium na serwerze z poziomu klienta?? Dopiero ponowne jego utworzenie (backup poprzez dump i restore poprzez load) pozwoliło mi ponownie dobrać się do kodu. Takie coś NIGDY nie powinno się wydarzyć, cokolwiek bym nie wyczyniał!
Podsumowując: dłuższe używanie SVN prawie zawsze kończy się u mnie wyrykiwaniem bluzgów w histerycznym napadzie wściekłości i okładaniem pięściami mojej biednej klawiatury. Wystarczy tylko wyjść poza update/commit bez zmiany struktury plików i katalogów. Albo coś jest nie tak ze mną (po prostu: jestem debilem) albo to jednak SVN… szwankuje?
Pewnie wielu z Was obstawiło teraz pierwszą opcję (myśląc sobie “co za kretyn” ;) ), ale przed wydawaniem ostatecznego wyroku odpowiedzcie sobie na pytanie: czy nigdy nie czuliście lekkiego niepokoju, dreszczyku emocji, ew. znamion podświadomego wewnętrznego sprzeciwu wywołując komendę “Create branch”? Spowodowanych oczywiście myślą “no dobra, ale jak ja to potem k… złączę?“. Zakładanie locków, jak sugeruje jedna z odpowiedzi w serwisie devpytania, NIE JEST rozwiązaniem problemu – tylko prymitywnym i nieładnym półśrodkiem. Podobnie jak krzyczenie do kolegów w pokoju “nie ruszać projektu X, teraz JA na nim pracuję!”
Problemy z ideą scentralizowanych systemów kontroli wersji
Przejdźmy dalej… Subversion jest tzw. scentralizowanym systemem kontroli wersji, czyli zakłada istnienie dostępnego dla wszystkich serwera przechowującego główne repozytorium z całą historią, logami, gałęziami, tagami itd. Każdy klient może podpiąć się, ściągnąć sobie aktualny (bądź przeszły) stan repozytorium, a następnie dodawać swoje zmiany. Takie podejście może wydawać się OK, ale ma kilka wad…
Na przykład CZAS potrzebny na wykonanie jakiejkolwiek zdalnej operacji. Przejrzenie logów, zrobienie diffa, zapoznanie się z historią – wszystko to wymaga podłączenia się do zdalnego serwera i uzyskanie z niego żądanych informacji. A to trwa. Trwa DŁUGO. Można by założyć, że w środowisku korporacyjnym, gdzie cały ruch idzie po bardzo szybkim lokalnym łączu (chociaż nawet środowisko korporacyjne może być rozproszone, ale nie o takie mi chodzi:) ), nie zauważymy problemu. I prawdę mówiąc można z takim założeniem żyć całkiem długo, dopóki nie spróbuje się alternatywy. Nawet ja w swojej konfiguracji opisanej wyżej (wszystko na JEDNEJ fizycznej maszynie) doświadczyłem ogromnej różnicy.
Innym problemem jest praca offline, bez połączenia z centralnym repozytorium. Teoretycznie w większości przypadków (a przynajmniej w SVN) jest to możliwe. Co jednak gdy taki stan offline się przeciąga? Wiem coś o tym – kiedyś zdalny serwer po prostu się zjarał a na nowy czekaliśmy dwa tygodnie. Dwa tygodnie bez logów. Dwa tygodnie bez historii. Wreszcie – dwa tygodnie bez commita! Wyobrażacie sobie GIGANTYCZNY burdel w moim working copy po tych dwóch tygodniach? Ma-sa-kra.
Na szczęście jest…
Alternatywa
Narzekanie nie miałoby sensu, gdyby nie dałoby się sytuacji naprawić. Alternatywą nie tyle dla SVNa, co dla każdego systemu kontroli wersji zrealizowanego w modelu scentralizowanym jest model… rozproszony (a to ci siurpryza!).
Czyli na przykład GIt. Albo na przykład Mercurial. Albo na przykład Bazaar… Możliwości jest wiele.
Nie będę się rozwodził nad teorią, ale bardzo gorąco (jea) zachęcam do zapoznania się z jakimiś materiałami na ten temat (albo w Google, albo w paragrafie “A few of the advantages of distributed revision control” w książce o Mercurialu, albo gdziekolwiek indziej pod hasłem Distributed Version Control System – DVCS). Idea jest bardzo prosta: każdy programista ma u siebie KOMPLETNE repozytorium, z całą historią, ze wszystkimi logami, ze wszystkimi gałęziami. Dzięki temu operacje na repozytorium są BŁYSKAWICZNE. Dzięki temu można wykonywać lokalne commity i lokalne odgałęzienia. Dzięki temu wreszcie – żadna awaria żadnego centralnego serwera nam nie zaszkodzi! Zmienia to całkowicie sposób pracy i myślenie o kontroli wersji – po prostu tak to powinno wyglądać!
Ja aktualnie korzystam z Gita, o którym więcej postaram się popisać w niedalekiej przyszłości. On jest ostatnio bardzo “trendy”, ale także ma swoje wady. Dwie główne to dla mnie: 1) nie jest to narzędzie napisane z myślą o pracy na Windows (w końcu napisał je Linus Torvalds:) ) i to się niestety czuje; 2) sprawne posługiwanie się nim wymaga trochę nauki, czasu i cierpliwości.
Zrobiłem też niedawno krótki research w temacie Mercuriala i rozwiązanie to po prostu mnie zachwyciło. Jeśli myślisz o przejściu na DVCS, polecam rozpoczęcie rozpoznania tematu właśnie od tego systemu.
A jakie Wy macie doświadczenia z systemami kontroli wersji? Czego używacie, co polecacie? Czy ktokolwiek doświadczył podobnych problemów przy korzystaniu z Subversion?
