Karol „Zal” Zalewski

Systemy kontroli wersji pokroju SVN, Mercuriala, czy też Gita to świetne rozwiązanie, które znacząco ułatwia nie tylko samodzielną pracę nad projektami informatycznymi, ale również sprzyja pracy grupowej. Chyba każdy, kto miał okazję wspólnej pracy nad treścią dłuższego dokumentu doceni połączenie LaTeX-a oraz któregoś z wymienionych systemów. Istnieją jednak takie sytuacje, kiedy to systemy kontroli wersji zupełnie nie sprawdzają się. Ostatnie chwile przed deadlinem, kiedy to cała grupa intensywnie pracuje nad dokumentem, są źródłem konfliktów, które co i rusz należy rozwiązywać. A przecież blokada konkretnego pliku w tak delikatnym okresie nie wchodzi w grę. Jak sobie z tym poradzić? To proste. Wystarczy skorzystać z „notatnika w wersji multiplayer”. Oto krótki opis oprogramowania, które dostarcza wspomnianą funkcjonalność i znacząco ułatwia pracę w zespole.

Kiedyś już wspominałem o polskim projekcie o nazwie MoonEdit. Program ten, o zamkniętym kodzie źródłowym (freeware do użytku niekomercyjnego), będąc narzędziem wieloplatformowym umożliwia wspólną edycję jednego pliku przez kilka osób w tym samym czasie. Wszystko odbywa się w czasie rzeczywistym, a zmiany oznaczane są kolorami przyporządkowanymi do użytkownika, który danej modyfikacji dokonał. Świetna sprawa, która w znaczący sposób ułatwia wspólną pracę nad jednym dokumentem. Przypomina to w pewnym stopniu to, co mogą zaobserwować użytkownicy usług Google o nazwie Google Docs (ew. LaTeX Lab - otwartoźródłowy edytor LaTeX-a oparty o Google Docs) oraz Google Wave. Wszystkie te rozwiązania mają jednak co najmniej jedną, acz istotną, wadę. Ich licencje oraz sposób funkcjonowania sprawiają, iż ich wykorzystanie jest ograniczone. Warto zatem poszukać wolnego oprogramowania, które pełni rolę takiego sieciowego notatnika. Takim programem jest Gobby.

Gobby to wieloplatformowy projekt rozwijany od 2005, a dostępny na licencji GPL, który całkiem nieźle sprawdza się podczas grupowej edycji dokumentów. Szczególnie, jeżeli mowa o kodach źródłowych oraz plikach z kodem w LaTeX-u. Możliwość pracy na kilku plikach jednocześnie, osobny kanał komunikacyjny dla osób uczestniczących w tworzeniu (coś ala IRC), szyfrowane połączenia, ochrona pliku hasłem, podświetlanie składni, czy też wsparcie dla Unicode to tylko niektóre z cech Gobbiego. Samą aplikację znajdziecie w repozytoriach takich dystrybucji Linuksa, jak np. Debian, czy też Ubuntu. Warto również podkreślić, że Gobby ułatwia pracę deweloperom podczas Ubuntu Developer Summit. Także członkowie projektu Fedora mają z nim stosunkowo często do czynienia.

Gdybyście mieli ochotę zapoznać się z Gobbim to polecam na sam początek wypróbować wersję starszą, niż 0.4.90. Dlaczego? Starsze wersje pomimo braku funkcjonalności redo/undo posiadają nieco prostszy interfejs użytkownika oraz serwer wbudowany w klienta, który można uruchomić jednym kliknięciem myszy (serwer dedykowany tj. Sobby jest opcjonalny).

Zachęcam do wypróbowania Gobbiego lub innych rozwiązań tego pokroju. To naprawdę ułatwia pracę i umożliwia skupienie się na tym, co najważniejsze bez potrzeby tracenia energii na zabawę w rozwiązywanie konfliktów, czy siedzenie przed jednym komputerem.

Google ogłosiło nie dalej, jak cztery dni temu, iż Google Code już oficjalnie wspiera projekty realizowane z wykorzystaniem rozproszonego systemu kontroli wersji znanym pod nazwą Mercurial.

Wygląda na to, iż Hg powoli staje się równie popularnym rozwiązaniem pośród DVCS, jak Subversion pośród scentralizowanych projektów. Świadczy o tym natywne wsparcie dla niego m.in. w IDE NetBeans, istnienie oprogramowania pokroju TortoiseHg (Windows), czy też darmowy hosting kodu na Assembli oraz Google Code.

Co ciekawe, zainteresowanie Mercurialem objawia się u Google np. wspieraniem developerów TortoiseHg (kupno sprzętu). Można też przeczytać porównanie Gita z Mercurialem wykonane przez Google. Prostota obsługi, świetna dokumentacja, silne wsparcie ze strony innych aplikacji i dopracowany protokół wykorzystujący HTTP to główne atuty Mercuriala według Google.

Prosty pomysł - powiadamianie o zmianach w repozytoriach Subversion, Mercurial itp. poprzez Jabbera. Z wykonaniem jest już nieco gorzej. Niestety, nigdzie nie znalazłem jabberowego bota (będącego najbardziej uniwersalnym rozwiązaniem), który by to umożliwiał. Brak też jakichkolwiek wzmianek o podobnym rozwiązaniu będącym np. rozszerzeniem do Traca. Istnieją natomiast inne, nieco mniej eleganckie rozwiązania. Oto i one.

Obecnie chyba każdy system kontroli wersji umożliwia wykorzystanie tzw. "post-commit hooka". Innymi słowy - umożliwia automatyczne wykonanie pewnej czynności po wystąpieniu uaktualnienia repozytorium. Dzięki temu rozwiązaniu można skorzystać np. ze skryptów Lennona Day-Reynoldsa (skrypt w Rubim dla SVN-a), czy też CommitBota (skrypt w Pythonie dla Gita). Niestety, wspomnianego rozwiązania raczej nie wykorzystamy w serwisach pokroju Assembli, Google Code, czy też GitHuba. Trudno też określić ich stabilność i skuteczność.

Najmniej finezyjnym rozwiązaniem byłoby najprawdopodobniej wykorzystanie feeda RSS ze zmianami w repozytorium udostępnianego przez wszelkiej maści serwisy. Połączyć to z jabberowym botem służącym do czytania RSS-ów i mamy coś, co mogłoby służyć za wspomniany system powiadomień.

PS. Chociaż można też pokusić się o jeszcze inne rozwiązanie w przypadku np. Assembli, która posiada możliwość m.in. powiadamiania o zmianach przez e-mail, Twittera, czy też z wykorzystaniem "Webhook".

Jako, iż kilka dni temu rozpoczęliśmy czteroosobowy projekt grupowy o kodowej nazwie "Truteń" zastanawiamy się nad tym, jak efektywnie rozwiązać komunikację oraz zarządzanie grupą. Obecnie mamy zamiar wykorzystać niepubliczne repozytorium SVN w celu składowania kodu w Javie i dokumentacji w LaTeX-u, kanał IRC-owy do prowadzenia konferencji oraz listę mailingową do przesyłania ogłoszeń i Jabbera do komunikacji w mniej nagłych przypadkach. Możliwe, że na późniejszych etapach przyda się również VPN do testów oraz Bugzilla do zgłaszania bugów.

Całkiem poważnie zastanawiam się nad wdrożeniem VoIP-a, czy też innego rozwiązania umożliwiającego prowadzenie telekonferencji. Skype, ze względu na swój niewolny charakter raczej odpada. Do kamer też nie mamy szerszego dostępu, więc wideokonferencje nie mają prawa bytu. Przydałoby się również narzędzie do zarządzania czasem, wyznaczaniem zadań i kamieni milowych. Coś opartego np. o tickety i osadzone na jednym z dostępnych nam serwerów (interfejs webowy lub klient). Znacie takie rozwiązania? Orientujecie się może, co byłoby najwygodniejsze - najlepiej oprogramowanie typu FLOSS nastawione na pracę sieciową?

Powracając do indywidualnych planów - mam zamiar w najbliższym czasie zabrać się za przystosowanie VIM-a do pracy w ramach prostego IDE dla C oraz Javy. Będzie to niezbędne, ponieważ planuję pracować na komputerach w laboratorium na WETI, które są dostępne poprzez SSH. Zabawa MPI, czy też PVM wymaga, aby mieć dostęp przynajmniej do najprostszego klastra (OpenMosix i domowa sieć to nie to samo). Postaram się też przetestować graficzne nakładki na klienta SVN-a, które przydałyby się do wspomożenia ww. pracy grupowej. O ile TortoiseSVN sprawdza się świetnie pod Windowsem, tak pod Linuksem jest kilka niesprawdzonych przeze mnie narzędzi. Poprzednio w zupełności wystarczały narzędzia konsolowe plus to, co dostarczała Assembla. Obecnie z tego drugiego korzystać nie chcemy.

CVS to przeszłość. Scentralizowany SVN radzi sobie całkiem nieźle, ale... Może czas rozważyć wykorzystanie rozproszonego systemu kontroli wersji np. Gita lub Bazaara?

Zacznijmy może od darmowych serwisów udostępniających repozytoria Gita i Bazaara. Z tym na całe szczęście problemów większych nie ma - Assembla i GitHub dla Gita (a ten pierwszy i dla SVN-a) oraz Launchpad dla Bazaara.

Bazaar ma jednak pewną przewagę nad Gitem - lepiej radzi sobie z wieloplatformowością ze względu na to, iż został napisany w Pythonie (w przypadku Gita - C). Może też zawsze działać, jako system scentralizowany. Natomiast, jeżeli chodzi o wykorzystanie to Git ma moim zdaniem większe "sławy" na swoim koncie: Wine, X.org, Fedora, Ruby on Rails, czy też jądro Linuksa (w tym celu stworzony) vs Launchpad, Squid, MySQL, czy też Apt w przypadku Bazaara.

Pytanie do osób lepiej zorientowanych w temacie - co wybrać?

Ohloh to serwis stworzony w 2006 roku przeznaczony dla programistów i osób zarządzającymi projektami informatycznym, które chciałyby uzyskać interesujące narzędzie do prowadzenia statystyk dot. tworzonego projektu.

Wystarczy stworzyć stronę projektu, podać informacje dotyczące repozytoriów kodu (CVS, SVN lub Git) i voilà! Przykładem może być tutaj Firefoks, czy też Serpentyna. Otrzymujemy informacje na temat tego, kto i jak aktywnie uczestniczył w tworzeniu kodu, w jakich językach został on napisany, w jakim stopniu jest skomentowany itp.

Nie jest to może narzędzie, które jest niezbędne przy realizacji projektu, ale z pewnością przyda się podczas nadzorowania prac. Szczególnie, gdy mowa o prostych aplikacjach tworzonych w duchu FLOSS.

Jakiś dalej, jak wczoraj wspominałem Wam o udanej próbie zmuszenia MS Visual Studio do pracy z SVN-em. Klienta zatem już mamy. A co z serwerem?

Nie każdy ma okazję postawienia własnego serwera SVN-a. W takim przypadku warto zainteresować się darmowymi rozwiązaniami, które do zadań niekomercyjnych często w zupełności wystarczają ;-] Oto i one!

Assembla - w skrócie: ogromne możliwości związane z zarządzaniem projektem i pracą grupową, 200 MiB na repozytorium (SVN, Git oraz Mercurial) oraz... żadnej wzmianki o zasadach użytkowania. Trudno nawet określić, czy dotyczy on w wersji bezpłatnej jedynie projektów Open Source. Niemniej jednak wielu użytkowników wskazuje na to, iż licencja projektów nie jest w żaden sposób wymuszana, a sam serwis jest godny polecenia.

BountySource - interesujący hosting opierający się o SVN oraz Otwarte Oprogramowanie. Umożliwia proste zarządzanie projektem oraz przekazywanie tzw. nagród. Brak informacji o ograniczeniach licencji projektu, czy też objętości kodu. Warto również wspomnieć o jasnych warunkach użycia.

CVSDude - nawet nie warto wspominać o tejże usłudze ;-) Udostępnia serwer CVS-a oraz SVN-a, ale... ograniczając całkowitą objętość repozytorium do 2 MiB i możliwość dostępu jedynie przez jednego użytkownika! Może w wersjach płatnych lepiej to wygląda. W ostateczności można spróbować wysłać maila do obsługi w momencie tworzenia oprogramowania Open Source - wtedy warunki są możliwe do negocjacji. Warunki usługi nie odróżniają się zbytnio od innych.

Github - "We're down for maintenance." ;-D Uzupełnię ten fragment po tym, jak serwis wstanie.

Google Code - hosting ze stajni Google przeznaczony dla niekomercyjnych projektów Open Source. Na dzień dobry otrzymujemy dostęp do SVN-a z limitem objętości repozytorium do 100 MiB. Do tego dochodzi miejsce dla plików (też 100 MiB), Wiki projektu oraz proste zarządzanie znalezionymi błędami. Stosunkowo wolna i mało funkcjonalna oferta. Warunki usługi nie zaskakują.

Launchpad - hosting Canonicala dla projektów Open Source. W przeciwieństwie do innych tego typu usług, na Launchpadzie jedynym właściwym systemem kontroli wersji jest Bazaar. Do tego dochodzi tracker (nie tylko kodu, ale również błędów), własne repozytorium dla Ubuntu oraz system wspomagania tłumaczenia projektu. Kolejny raz nikt nie wspomina o ograniczeniach pojemnościowych usługi. Na twórców projektu nałożone jest jednak sporo ograniczeń związanych z licencją. Reszta warunków bardzo przejrzysta.

SourceForge.net - to chyba jedna z najstarszych usług związanych z Otwartym Oprogramowaniem. Udostępnia serwer CVS-a, SVN-a, Wiki, trackera, możliwość udostępniania plików, serwer WWW wraz z bazą danych (PHP, MySQL, możliwość podpięcia własnej domeny oraz obsługę Perla, Pythona, Tcl i Rubiego poprzez CGI) oraz narzędzia związane z zarządzaniem projektu. Czytając warunki użytku znalazłem informację o tym, iż wszystkie programy umieszczane na SourceForge.net muszą być Otwartym Oprogramowaniem. W całym serwisie nie znalazłem informacji odnośnie ograniczeń pojemnościowych wspomnianych usług. Zastrzegają sobie również prawa do tego, aby w przyszłości móc wykorzystać pozostawiony u nich kod do rozbudowy ich serwisu. Z tego, co widzę jest to typowe zagranie tego typu serwisów - np. Google Code.

Unfuddle - hosting wspierający repozytoria Git oraz SVN. W wersji bezpłatnej najeżony ograniczeniami. Na repozytoria można przeznaczyć 200 MiB, co jest normą. Problemem okazuje się liczba osób mogących uczestniczyć w projekcie - 2. Zaletą jest brak obostrzeń dot. licencji hostowanego projektu. W warunkach użytkowania usługi nie znalazłem niczego, co mogłoby mnie bardziej zrazić do usługi.

W przypadku, gdyby ktoś gustował w przeżyciach podnoszących adrenalinę warto zainteresować się serwisem OpenSVN. Dlaczego? Zdarzyło im się nie tylko przejść w stan offline na dwa tygodnie, ale również utracić część projektów...

A Wy, które z nich polecacie? Może znacie inne darmowe oferty? Zapraszam do dyskusji! :-)

Do tej pory pracując w zespole studenckim (pozdrowienia dla Owcy i Psychola) pisaliśmy głównie projekty w Javie. Wykonując je korzystaliśmy z dwóch najpopularniejszych IDE - NetBeans oraz Eclipse. Narzędzia te nie miały żadnego problemu z wewnętrzną obsługą systemów kontroli wersji takich, jak CVS, czy też SVN, z którego to właśnie korzystaliśmy. Czasy się jednak zmieniają...

Obecny projekt mamy zamiar napisać korzystając z C♯ oraz Microsoft Visual Studio 2005 (darmowa wersja pobrana z MSDNAA). I tutaj zaczynają się schody - Visual Studio 2005 nie posiada natywnego wsparcia dla SVN. Jak sobie z tym poradzić nie wydając pieniędzy i działając w świetle prawa?

Mamy na to sposób ;-)

AnkhSVN został zapoczątkowany, jako projekt na ostatnim roku studiów przez Arilda Finesa. Co najważniejsze, jego rozwój był nadzorowany przez Karla Fogela - jednego z ojców Subversion. Przeznaczony dla Visual Studio 2002, 2003 (wersja 1.x) oraz nowszych (wersja 2.x) bezproblemowo integruje się ze wspomnianym IDE. Jeszcze dwa lata temu zawierał sporo bugów, ale teraz sytuacja uległa znaczącej poprawie. Polecam to rozwiązanie.

TortoiseSVN nie jest niestety wtyczką do Visual Studio, ale... Został stworzony do obsługi SVN-a i robi to doskonale! Bezproblemowo integruje się z eksploratorem Windowsa, a w związku z tym jest niezależny od IDE. Polecany przez wielu programistów.

Wspomnieć można jeszcze o VisualSVN. Projekt płatny, wymagający do poprawnego działania TortoiseSVN, a do tego nie jest tak dobry, jak AnkhSVN ;-)

PS. Przy okazji znaleźliśmy świetny program do tworzenia prostych diagramów Gantta. Darmowy, wieloplatformowy (Java) GanttProject. Według naszego diagramu na niniejszą notkę miałem czas do najbliższego czwartku ;-D

Posiadacze routerów Linksysa z serii WRT54GL (i innych) z pewnością myśleli kiedyś nad instalacją alternatywnego oprogramowania. DD-WRT/OpenWRT wraz z modyfikacją polegającą na dodaniu wsparcia dla kart SD to dobry początek, jeżeli myśli się o małym, cichym serwerze działającym w trybie 24/7.

Dzisiaj pokażę Wam, jak postawić na wspomnianym routerze (i nie tylko) serwer SVN ze wsparciem dla SASL. Do edycji plików polecam edytor Vi.

Po pierwsze: potrzebny nam jest dostęp do pakietów z OptWare. Opis instalacji wsparcia dla OptWare można znaleźć na Wiki projektu DD-WRT. Korzystając z poniższych komend na routerze należy zainstalować pakiety svn oraz cyrus-sasl wraz z zależnościami:

ipkg install svn
ipkg install cyrus-sasl

Po drugie: należy zatroszczyć się o to, aby serwer SVN był włączany przy każdym starcie routera. W skryptach startowych (DD-WRT: interfejs webowy, Administration -> Commands -> Startup) należy dodać poniższą linijkę:

/opt/bin/svnserve --daemon --root=/katalog_glowny_repo_SVN

Po trzecie: po utworzeniu własnego repozytorium (komenda svnadmin create nazwa_repo w katalogu głównym repozytoriów) warto zainteresować się plikami znajdującymi się w katalogu głównym repozytorium. Mowa o pliku /scieżka_do_repo/conf/svnserve.conf w którym to powinny znaleźć się następujące linie:

[general]
anon-access = read
auth-access = write
authz-db = authz

realm = Identyfikator_repo_bez_spacji

[sasl]
use-sasl = true
min-encryption = 0
max-encryption = 256

Zmienna realm jest tutaj niezwykle istotna. Dla każdej takiej zmiennej osobno będziemy dodawać użytkowników, dlatego też, jeżeli dwa repozytoria będą posiadać taką samą zmienną realm to będą też dzielić użytkowników mogących z nich korzystać. Zmienne min-encryption oraz max-encryption mówią o tym, jakie długości kluczy będą możliwe do wykorzystania podczas szyfrowania przesyłanych danych (0 - oznacza brak szyfrowania, 1 - jedynie podpis cyfrowy przesyłanych danych). Uwaga! Aby anonimowy użytkownik mógł pobierać dane z repozytorium bez podawania hasła zmienna min-encryption musi wynosić 0, a w poniżej opisanym pliku musi się znaleźć opcja ANONYMOUS. Warto też zatroszczyć się o istnienie pliku authz w katalogu z svnserve.conf z regułami dostępu do repozytorium (szerszy opis w samym pliku, który powstanie po utworzeniu nowego repozytorium).

Po czwarte: należy utworzyć plik /opt/lib/sasl2/svn.conf o następującej zawartości:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: ANONYMOUS DIGEST-MD5

Możliwe do wykorzystania mechanizmy (mech_list) są opisane w dokumentach zawartych katalogu /doc/ w paczce z Cyrus SASL. Skupmy się na umieszczonych powyżej - DIGEST-MD5 umożliwia autoryzowanie oraz szyfrowanie połączeń z użytkownikami zawartymi w pliku /opt/etc/sasl2 (powstanie po pierwszym utworzeniu użytkownika), który to musi posiadać uprawnienia umożliwiające odczytanie go przez program svnserve. ANONYMOUS umożliwia natomiast pobranie danych bez posiadania konta na serwerze SVN (konieczna jest modyfikacja w pliku svnserve.conf - patrz wyżej). Uwaga! Przy metodzie DIGEST-MD5 hasła w pliku sasl2 są przechowywane w formie czystego tekstu.

Jak dodać użytkownika? To proste - wystarczy wydać polecenie:

saslpasswd2 -c -u zmienna_realm nazwa_użytkownika

Pamiętajcie o tym, aby zmienna realm odpowiadała tej ustawionej w pliku konfiguracyjnym repozytorium. Po wydaniu polecenia zostaniecie poproszeni o dwukrotne powtórzenie hasła użytkownika i... to wszystko ;-) Serwer działa!

Wszystkich użytkowników w systemie można wylistować komendą sasldblistusers2, a usuwać komendą saslpasswd2 -d -u zmienna_realm nazwa_użytkownika.

Po piąte: Ubuntu 8.04 nie posiada we własnym repozytorium klienta w wersji wyższej, niż 1.4.x. Zaś klient w wersji 1.5.x jest wymagany w celu pełnej współpracy z serwerem SVN w ww. konfiguracji. Aby uzyskać dostęp do nowszego klienta należy dodać listy repozytoriów odpowiednie (zawierające nową wersję klienta) repozytorium. Należy to zrobić poprzez dodanie do pliku /etc/apt/sources.list następujących linii:

deb http://ppa.launchpad.net/clazzes.org/ubuntu hardy main
deb-src http://ppa.launchpad.net/clazzes.org/ubuntu hardy main

Teraz wystarczy zaktualizować listę pakietów (sudo aptitude update) oraz uaktualnić pakiet subversion.

Powyższa konfiguracja nie wymaga, aby każda osoba chcąca pobrać dane z serwera SVN posiadała własnego użytkownika oraz hasło. Może je pobrać anonimowo nie korzystając z szyfrowania. Tak, jak to robię poniżej:

svn checkout svn://svn.serwer.net/repozytorium

A tak wygląda zgłaszanie nowego kodu dla użytkownika, który spełnia odpowiednie reguły.

svn commit --username nazwa_użytkownika -m "Drobna zmiana"