Rozproszona kontrola wersji to jest to, dziecinko

Oryginalny post: Distributed Version Control is here to stay, baby

Autor: Joel Spolsky

Jakiś czas temu Jeff i ja zaprosiliśmy Erica Sinka do podcastu Stack Overflow i narzekaliśmy na kontrolę wersji, zwłaszcza na modne, nowe rozproszone systemy kontroli wersji, takie jak Mercurial i Git.

W tamtym odcinku powiedziałem "Według mnie to, że tworzenie nowych gałęzi i ich łączenie jest łatwiejsze spowoduje, iż twoi współpracownicy będą częściej wykorzystywać te funkcje, co sprawi, że ciężko będzie się w tym wszystkim połapać."

Wiecie, podcast nie jest wcześniej drobiazgowo przygotowywany. Siedzimy sobie w kilka osób i urządzamy pogawędkę. Z tego powodu zazwyczaj nasze wypowiedzi są, używając technicznego sformułowania, błędne. Zazwyczaj błędny jest ogólny wydźwięk albo tylko szczegóły, lub wydźwięk i szczegóły, ale tym razem były po prostu naprawdę błędne. Jak truskawkowa pizza. Albo bajgiel z jalapeño. BŁĘDNE.

Na długo zanim podcast został wyemitowany, mój zespół zaczął używać Mercurial i ta zmiana naprawdę wszystko mi zagmatwała, więc zatrudniłem kogoś żeby wprowadzał dla mnie kod do repozytorium (żartuję). Walczyłem przez jakiś czas próbując zapamiętać kilka kluczowych komend, wyobrażając sobie, że wszystko działa tak jak w Subversion, ale kiedy coś nie działało tak jak w Subversion nie wiedziałem co mam dalej robić i byłem zmuszony biec po Benjamina lub Jacoba żeby mi pomogli.

Wtedy mój zespół obwieścił mi "Wiesz co? Ten Mercurial jest całkiem niezły i chcemy w oparciu o niego napisać produkt pozwalający na rewizję kodu, a co więcej wydaje nam się, że istnieje duży popyt na komercyjne wsparcie i hostowanie go" (sam w sobie Mercurial jest dostępny dla każdego na licencji GPL, ale wiele korporacji chce mieć jakieś wsparcie zanim zaczną czegoś używać).

Pomyślałem sobie, co ja tam wiem? Jak pewnie wiecie, ja nie mam tutaj ostatniego słowa, ponieważ "zarządzanie to funkcja wspierająca", więc zabrali wszystkich stażystów, wszystkich sześcioro i zaczęli tworzyć aplikację opartą na Mercurial.

Postanowiłem dowiedzieć się, o co chodzi z tą całą "rozproszoną kontrolą wersji" zanim ktoś zada mi pytanie o produkt, który podobno moja firma sprzedaje, a ja nie będę wiedział, co odpowiedzieć i ktoś znowu obsmaruje mnie w blogo-"sferze".

Drążyłem, drążyłem i w końcu coś wymyśliłem. Coś czym chcę się z Wami podzielić.

W rozproszonych systemach kontroli wersji, rozproszenie nie jest najistotniejsze.

Istotne jest to, że te systemy działają w kontekście zmian, a nie wersji.

To brzmi bardzo "zen", wiem. Tradycyjne systemy kontroli wersji działają tak: OK, mam wersję 1. To jest wersja 2. A to jest wersja 3.

Rozproszony system działa tak: Nie mam nic. A teraz wprowadzono te zmiany. A teraz ktoś wprowadził te inne zmiany.

To inny Model Programu, więc model użytkownika też się musi zmienić.

W Subversion myślisz sobie "uaktualnij moją wersję, żeby była taka sama jak główna wersja" albo "cofnij się do poprzedniej wersji".

W Mercurial myślisz "daj mi zestaw zmian Jacoba" albo "zapomnijmy o tych zmianach".

Jeśli podchodzisz do Mercurial z nastawieniem na Subversion, wszystko będzie prawie działać, ale kiedy nie będzie, wszystko Ci się pomiesza, będziesz niezadowolony i go znienawidzisz.

Kiedy uwolnisz swój umysł, ponownie wyobrazisz sobie kontrolę wersji i pojmiesz zen różnicy między zarządzaniem wersjami, a zarządzaniem zmianami zostaniesz oświecony i z radością zdasz sobie sprawę, że właśnie w ten sposób powinna działać kontrola wersji.

Wiem, że to dziwne... od 1972 wszyscy myśleli, że operują na wersjach, a teraz zaskakująco okazuje się, że myślenie przede wszystkim o zmianach samych w sobie rozwiązało bardzo istotny problem: łączenia gałęzi kodu.

Oto najważniejszy wniosek, a właściwie, najważniejsza rzecz, której dowiedzieliśmy się o produktywności deweloperów w ciągu ostatniej dekady. Jest to tak istotne, że zasługuje na to, aby być ostatnią opinią jaką napiszę, więc jeśli zapamiętasz tylko jedną rzecz to zapamiętaj to:

Kiedy zarządzasz zmianami zamiast wersjami, łączenie gałęzi działa lepiej, a przez to możesz rozgałęziać kod kiedy tylko wymagają tego twoje cele organizacyjne, ponieważ ponowne ich łączenie to kaszka z mleczkiem.

Nie potrafię powiedzieć ilu użytkowników Subversion opowiada taką historię: "Spróbowaliśmy stworzyć nową gałąź i to działało dobrze. Kiedy przyszedł czas żeby połączyć ją z powrotem to był absolutny koszmar i musieliśmy praktycznie każdą zmianę wprowadzać ręcznie przysięgając sobie, że nigdy więcej, a nawet wypracowaliśmy specjalny sposób pisania z instrukcjami if zamiast gałęzi."

Czasami są nawet dumni ze swojej inwencji korzystania z pojedynczej głównej gałęzi. Tak jakby było zaletą to, że muszą obchodzić sposób działania ich systemu kontroli, który nie potrafi zrobić co do niego należy.

Z rozproszonym systemem kontroli, łączenie jest łatwe i działa jak należy. Więc naprawdę możesz mieć gałąź stabilną i rozwojową albo tworzyć długożyjące gałęzie dla swojego zespołu kontroli jakości, który wykonuje testy przed wdrożeniem, albo krótkożyjące gałęzie po to, żeby wypróbowywać pomysły i zobaczyć jak będą się sprawować.

To zbyt ważne, żeby to pominąć. Być może jest to największy postęp jaki dokonał się w dziedzinie tworzenia oprogramowania w ciągu tych 10 lat przez które pisałem tutaj artykuły.

Innymi słowy, prędzej wrócę do C++, niż zrezygnuję z Mercurial.

Jeśli używasz Subversion, proszę przestań. Po prostu przestań. Subversion = pijawki. Mercurial i Git = antybiotyki. Mamy teraz odpowiednią technologię.

Z powodu tego, że ludzie nurkują w Mercurial bez pełnego zrozumienia modelu na jakim pracuje program przez co mogą odnieść wrażenie, że jest zepsuty albo złośliwy, napisałem tutorial o Mercurial HgInit.

Dzisiaj, kiedy ktoś pyta mnie o tamten podcast o rozproszonych systemach kontroli wersji, mówię, że był to drobiazgowo planowany podstęp wobec mojego długoletniego przyjaciela i konkurenta Erica Sinka, który buduje nierozproszony system kontroli wersji. Tak jak wtedy kiedy zaczął sprzedawać oprogramowanie do śledzenia błędów i ukaraliśmy go wysyłając mu wypasiony plecak Fog Creek z lipnym oficjalnym listem, z którego wynikało, że idzie nam tak dobrze, że ten drogi plecak był standardowym gwiazdkowym prezentem, który wysyłamy każdemu klientowi korzystającemu z FogBugz.

Chyba kończy mi się czas. To wielki zaszczyt, że czytaliście moje wypracowania przez ostatnie 10 lat. Nie mógłbym prosić o lepszych czytelników. Niezależnie od tego, czy należysz do setek ludzi, którzy poświęcają swój czas, aby tłumaczyć artykuły na ponad 40 języków, czy 22.894 osób, którzy napisali do mnie emaila, czy 50.838 osób zapisanych do newslettera lub 2.262.348 osób, które rocznie odwiedzają stronę i czytają część z 1067 artykułów jakie napisałem, serdecznie dziękuję Ci za uwagę.

Data publikacji oryginału: marzec 17, 2010

2 komentarze:

Anonimowy pisze...

Gość wie co mówi. Niedawno szukałem nowego systemu kontroli wersji, poprzedni nie zapewniał możliwości definiowania odpowiednich uprawnień. I systemy DVCS otworzyły mi oczy na nowe - o wiele lepsze podejście do tego problemu.
Naprawdę: jeśli używacie SubVersion czym prędzej wyrzućcie go do kosza .......

Polecam jeszcze mało znany DVCS: Plastic SCM http://www.plasticscm.com/ Naprawdę zaskoczył mnie tym co potrafi i możliwościami jakie daje.
Prosty w konfiguracji, szybki, integracja z kilkoma bugtracerami (mogła by być bardziej rozbudowana), świetny klient pod Windows (jest wersja Linux i Mac) - naprawdę polecam.

Anonimowy pisze...

Ze swojej strony mogę polecić RabbitVCS - nakładkę na Git i SVN (dla Ubuntu głównie, jest ppa). Jest mnóstwo niedoróbek, ale tak wygodnie integruje się z nautilusem i gedit, że nawet laik może tego używać bez konieczności zaglądania do konsoli.

Prześlij komentarz

Related Posts with Thumbnails