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 (wtrącenie: jeśli czyta to ktoś ignorujący te systemy, niechaj natychmiast się nawróci! to nie jest trudne, a naprawdę niezbędne!). Subversion było też (albo jest nadal) 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 (z dwojga złego – lepiej klawiatury niż Joanny:) ). 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?
Chwilowo używam GITa, ale jeszcze się nie zagłębiałem w to jak toto działa od środka, a z podejściem laickim niestety wygląda to tak jak piszesz – średnio fajnie się to obsługuje z poziomu Windows. Nie wiem też z jakiej formy obsługi GITa korzystasz – ja używam GITExtensions, ale bez integracji z VS. Szkoda też, że nie ma jeszcze integracji z VS2010 Beta.
Jakby to był wpis o systemie kontroli wersji, którego nie znam, to przyjąłbym, że jest jak piszesz i tyle. Używam svn (w dawnych czasach używałem vss) i używam go, bo ma branche. Korzystam z tego w kilkuosobowym zespole, merge jest częstą operacją i wszystko gra. Problemy zawsze wynikały z moich (czy kolegów) błędów, np. zamieszanie przy merge. Ale nawet jak się namiesza, to każdy commit da się wycofać i zrobić jeszcze raz poprawnie. Working copy mam od miesięcy to same (używam switch) i też działa. Jak zainstalowałem tortoise z wersją repository 1.6, a ankh obsługiwał wtedy 1.5 to miałem z tym chwilę bólu. Odinstalowałem tortotise, zainstalowałem wcześniejszy, użyłem change-svn.py i dalej działałem. Przy merge jest częsty konflikt z plikami projektów (xml zmieniany przez wiele osób i rozumiem że trudno go połączyć automagicznie), przyjmuję, że trzeba przejść przez ‘edit coflicts’. Więcej problemów nie pamiętam :)
Na serwerze mam wersję repository 1.4, na kliecie 1.6 i bałem się kiedyś, że to może powodować problemy, ale działa OK.
Zaniepokoił mnie ten tekst, ciekaw jestem czy ktoś jeszcze miał takie problemy jak Ty.
Artur
PS. Książki do svn nie czytałem, może to ona Ci namieszała? ;)
@leszcz: korzystam z konsoli. TortoiseGit tylko do 2 operacji: ShowChanges i Revert. Jak zaczynalem, integracja z VS (2008) okazala się zupelnie nieprzydatna.
@Artur: dlatego tez wyraznie zaznaczylem ze to tylko moje problemy, i ze sa one dziwne:). tak czy siak wchodze na jakąś minę prawie za kazdym razem… zdaje sobie sprawe ze SVN nie moze byc pelen bugów skoro caly swiat z niego korzysta, ale tak czy siak u mnie caly czas cos jest nie tak. Moze i moja wina… a moze faktycznie ksiazki:)
Również korzystam z branchów i merge’a bez problemów. Należy przede wszystkim pamiętać o jednej rzeczy – brancha trzeba co jakiś czas (w książce podają, że np. raz na tydzień) updejtować zmianami, które zachodzą w trunk’u, tak żeby były one w miarę zsynchroznizowane (trunk->branch), później łatwo jest zmergować brancha, bo zawiera już wszystkie zmiany z trunk’a.
Nigdy nie stało się tak, żeby repozytorium się niedostępne. Większości problemów także nie doświadczyłem. Jednak w tym co pisze Procent coś jest. Problemy typu tree conflict zdarzają się nagminnie. SVN z uporem maniaka proponuje mi zrobienie Clean, które i tak w większości wypadków nie pomaga. Co jakiś czas pojawiają się jak i czasami automagicznie znikają problemy typu, że SVN twierdzi, że w repozytorium są świeżo dodane pliki (które zresztą sam dopiero co dodawałem), co więcej próba zrobienia Update nic nie wnosi. Po prostu przez dłuższy czy krótszy czas pliki te wiszą sobie na liście zmian. Zauważyłem jedno, nie pamiętam podobnych problemów z projektami VS2005 gdzie nie wykorzystywałem Ankh’a. Tree conflict’y pojawiają mi się najczęściej przy dodawaniu całych katalogów z poziomu VS i Ankh.
bkBodzio:
Dokładnie mam takie same odczucia apropo Ankh, próbowałem go używać do ostatniego projektu ale po straceniu paru h na bezowocnej walce poddałem się i teraz wykorzystuję po prostu TortoiseSVN. Sytuacja była na tyle absurdalna, że tworzyłem nowy projekt, umieszczałem go w repozytorium, następnie generowałem sobie przy pomocy T4 parę plików które były automatycznie dodawane do projektu (T4 Toolbox) i po takiej zmianie mogłem zapomnieć że uda mi się zrobić Commit. Ciągłe komunikaty o potrzebie zrobienia Clean który nijak nie pomagał. Ręczna edycja na dłuższą metę była bezcelowa. W efekcie Ankh wyleciał, może Visual SVN lepszy ?
@Pawel:
"Dwustronne" merge, tzn najpierw trunk->branch a potem branch->trunk zawsze konczyly sie u mnie tragicznie. Ale faktycznie moze po prostu cos robilem zle…
@bkBodzio, @Dawid Kowalski:
Ja używam (używałem) VisualSVN i nie miałem żadnych problemów. Wrecz przeciwnie, on wprowadzil moja prace z SVN na kolejny poziom zadowolenia (oczywiscie do czasu).
Polecam wypróbować, przesadnie drogi nie jest.
Jakoś do tej pory nie korzystałem z tego narzędzia, ale chciałbym to zmienić.
Poszukam jakiegoś info na ten temat, jak się tym posługiwać, bo chyba to nie działa jak automatyczny backup.
Aż tak traumatycznych przeżyć z SVNem nie miałem, ale musze przyznać, że każda zmiana struktury plików na repozytorium wyowłuje u mnie dreszcz emocji ;)
Dzięki za zwrócenie uwagi na zdecentralizowane repozytoria, trzeba się będzie temu przyjrzeć bliżej.
Ja do codziennej pracy uzywam SmartGit’a – http://www.syntevo.com/smartgit/index.html . Dodatkowa zaleta tego narzedzia jest niezaleznosc od platformy.
@unodgs:
Dzięki za linka, nie natknąłem się wcześniej na to narzędzie. Zdecydowanie wypróbuję!
@Procent
"Dwustronne" merge, tzn najpierw trunk->branch a potem branch->trunk zawsze konczyly sie u mnie tragicznie. Ale faktycznie moze po prostu cos robilem zle…
1. Commit zmian do branch. (numerek revision x)
2. Merge trunk-> branch. Commit do branch (rev. y)
3. Merge branch-> trunk (ale nie biorę rev. y). Jak wezmę wszystkie rev. z gałęzi to w kodzie syf.
Podstawowa zasada, commit przed i po merge, bo można łatwo się wycofać.
@Dawid Kowalski, bkBodzio
Sporo błędów miało Ankh do vs2005. Np. nie można było zmieniać nazwy pliku i/lub lokalizacji, przed pierwszym odesłaniem go do repo (masakra). Ale korzystałem z niego omijając takie miny. Może dlatego z najnowszymi wersjami Ankh pracuje mi się bezboleśnie.
Artur
Artur:
Ja używam najnowszej wersji i VS2008, podejrzewam że pies leży pogrzebany w automatycznym dodawaniu plików do projektu, Anhk śledzi pewnie te zmiany a gdy ja to robię nie z poziomu IDE to głupieje. No trudno, narazie zostałem przy Tortoise.
@Procent: Ale tak właśnie należy mergować branche (tzw. feature branch) zgodnie z SVN book. :)
Ankh jest do bani, IMO, miałem z nim trochę problemów. Polecam VisualSVN (komercyjne, działa).
Może to lamerskie pytanie, ale czemu nie używać systemu do kontroli wersji stworzonego przez tego samego producenta, z którego IDE się korzysta? Mam tu na myśli Team Foundation Server – wydaje mi się, że w tym przypadku integracja z IDE jest chyba najlepsza. Nie mam za dużo doświadczenia, ale właśnie z tego narzędzia korzystam i jestem zadowolony (na razie)
@Pawel:
Tak czy siak, mi sie wielokrotnie nie udawalo i z tego co widzialem w praktyce (oraz widze w komentarzach) nie tylko ja mam problem z merge w svn:)
@kansas:
Z TFS korzystalem w 3 niezaleznych sytuacjach i z kazdym przypadkiem NIENAWIDZILEM tego narzedzia coraz bardziej. Kiedys pisalem na ten temat na CG, ale na osobny post na blogu sie nie odwaze – musialbym przypomniec sobie wszystko co mnie irytowalo (bo ostatnim razem korzystalem 2 lata temu). A najlepiej przypomina sie to przez praktyke, na co nie mam zdrowia:). W kazdym razie wszystkie wady wymienione wyzej znajduja zastosowanie w TFS, tylko jeszcze bardziej.
ja tylko dodam ze w firmie trzymamy kilkadziesiąt projektow na CVSie. Nie korzystalismy do tej pory z branches (chyba CVS jest w tyle z tym tematem) ale jednego jestem pewny, ani razu nie mielismy problemu z wysypaniem sie czy bledami o ktorych piszesz.
Ostatnio postawilem VisualSVN oraz sciagnalem klienta, zintegrowalem z VS i naprawde to niezle dziala. Czy bedzie dalej… zobaczymy na wiekszych projektach. Kiedys pracowalem na SVN przy 50 pod-projektach w solution VS2005 i był hardcore, pamietam cleany, commitowanie sobie zmian w poprzek i rózne cuda. I pamietam tez sciaganie calosci na dysk – dluugie sciaganie :(
Zaraz lookam na git-a, dobry temat poruszyles. Pozdrawiam
Nie wiem czy to się do czegoś przyda bo sam nie używałem tego narzędzia. Jest coś takiego jak TortoiseHG (http://tortoisehg.bitbucket.org/). Tutaj jest jakiś tutorial – http://draketo.de/light/english/mercurial/short-introduction-mercurial-tortoisehg.
Pozdrawiam
@CoMPi:
Dzięki, TortoiseHG jest spoko. Głównie ze względu na to że pokazywane przez niego ikonki póki co zawsze zgadzały się u mnie ze stanem faktycznym plików. W TortoiseSVN bywało różnie, a w TortoiseGit to już zupełna losowość:).
Moim zdaniem problemy z SVN w większości są winą nakładek a’la plugin do NetBeans’a, KdeSVN itp.
Co winien SVN jeśli nakładka przy imporcie każdy plik commit’uje osobno?
Pracowałem w dużej firmie, gdzie kilkadziesiąt osób pisało jedną aplikację customize’owaną dla różnych klientów, zatem wiele branch’ów oddzielających projekty, osobne branche do stabilizacji wersji przed release’ami i wszystko działało bez zarzutów. Merge’owaliśmy w te i wewte bardzo często.
Jedyne problemy polegały na rozjazdach w kodzie (logika aplikacji), ale SVN jako narzędzie działało bardzo dobrze.
Jeśli się ręcznie grzebie w katalogach .svn, usuwa pliki z poziomu systemu operacyjnego a nie przez SVN to nic dziwnego, że powstają błędy.
Z nakładek graficznych mogę polecić TortoiseSVN. Natomiast z IDE z rewelacyjną obsługą SVN polecam IntelliJ IDEA (w NetBeansie bałem się commite’ować, a tu wiem że będzie dobrze).