Zanim zajmiemy się stricte tym jak używać SVNa i narzędzi do niego, zapoznajmy się z kilkoma pojęciami które są kluczowe w pracy z systemami kontroli wersji:
Repozytorium (repository) - foldery i pliki znajdujące się na serwerze SVN. Repozytorium zawiera w sobie oprócz plików i katalogów, także historię zmian w tych danych. Dzięki temu możemy prześledzić każdą zmianę dokonaną w obrębie repozytorium.
Head - najnowsza wersja plików dostępnych w repozytorium (wersja aktualna).
Rewizja (revision) - dana "wersja" plików. Przy zatwierdzaniu zmian na serwerze, numer rewizj jest podnoszony o 1. Dzięki temu możemy przywrócić system do stanu np z rewizji numer 46. System przechowywania danych, ze względu na oszczędność miejsca, jest systemem przyrostowym. Oznacza to że zapamiętywane są tylko zmiany, nie zaś stan całego kodu.
Kopia robocza - nasza lokalna wersja kodów źródłowych. Możemy na niej dokonywać zmian, eksperymentować, bez ryzyka zniszczenia czy też uszkodzenia kodu. Zmiany które uznamy za poprawne wprowadzamy (commitujemy) do repozytorium.
Checkout - pobranie z repozytorium kodów w celu utworzenia swojej kopii roboczej.
Gałąź główna (trunk) - główna linia projektu. Bardzo często ta gałąź ma zawierać w sobie kod źródłowy który się kompiluje i przechodzi wszystkie napisane do niego testy.
Gałąź rozwojowa (branch) - gałąź "poboczna". W niej mogą być przechowywane nieskończone części kodu czy też kod zakończony częściowo. Kiedy w gałęzi tej kod zostanie już przetestowany i działa, można scalić ją z gałęzią główną.
Switch - przeskok między gałęziami w kopii roboczej.
Update - aktualizacja swojej kopii roboczej, plikami z repozytorium.
Commit - przesłanie naszych lokalnych zmian do repozytorium.
Merge (scalanie) - złączenie różnych gałęzi projektu w jedną.
Kolizja - sytuacja w której dany plik był modyfikowany przez różne osoby i w czasie scalania SVN nie mógł zdecydować która z wersji pliku jest poprawna. Musimy wtedy sami zdecydować którą wersję pliku uznać za właściwą.
Lock (blokada) - aby uniknąć sytuacji w której kilku programistów pracuje nad tym samym fragmentem kodu, można dane pliki zablokować. Po zablokowaniu inne osoby które chciałyby pracować nad danym plikiem, dostaną informację że nad tym plikiem ktoś już pracuje. Nakładanie locków pozwala uniknąć konfliktów przy mergowaniu.
Mając już podstawową wiedzę teoretyczną, zapoznajmy się z podstawowymi poleceniami jakie możemy wydawać z konsoli. Nie będę ich zbyt szczegółowo omawiał, ponieważ omówię narzędzia graficzne które bardzo ułatwiają pracę z systemami wersjonowania.
Tworzenie repozytorium
Tworzenie repozytorium z wiersza poleceń, jest relatywnie proste. Mając narzędzia Submin i WebSVN, musimy pamiętać tylko o tym, żeby tworzyć repozytoria w miejscach w których oba narzędzia je znajdą. Samo tworzenie repozytorium wygląda tak:
svnadmin create [nazwa repozytorium]
Tworzenie kopii roboczej
Utworzenie kopii roboczej, jest równoznaczne z pobraniem odpowiednich plików z serwera. Wykonamy to wpisując w wierszu poleceń następującą komendę:
Warto zauważyć że po utworzeniu kopii roboczej, w każdym katalogu będziemy mieli ukryty katalog .svn. Często jest w tych katalogach dużo plików, dlatego metoda "przeciągnij i upuść" w wypadku np. uploadowania projektu przez FTP może trwać bardzo długo.
Aktualizacja kopii roboczej
Aby zaktualizować naszą kopię roboczą, będąc w jej katalogu głównym wykonujemy następującą komendę:
svn update
Commit zmian na serwer
Przesłanie swoich zmian do głównego repozytorium także jest bardzo proste:
# Komentarz w którym opisujemy zmiany
svn commit -m "Komentarz"
I to by było na tyle jeśli chodzi o "konsolowe" podstawy. W następnej części zapoznamy się z Subminem.
Ostatnio stawiając serwer deweloperski, spotkałem się z zadaniem postawienia na nim Subversion. Proces stawiania i konfiguracji SVNa miałem przygotować też na zajęcia, więc skoro i tak muszę zebrać to i spisać, postanowiłem zrobić z tego wpis.
Co to jest SVN i z czym to się je?
Subversion (znany również jako SVN) – system kontroli wersji, który powstał w celu zastąpienia CVS. SVN jest wolnym i otwartym oprogramowaniem na licencji Apache.
System kontroli wersji sam w sobie służy do śledzenia zmian głównie w kodzie źródłowym oraz pomocy programistom w łączeniu i modyfikacji zmian dokonanych przez wiele osób w różnych momentach. Mówiąc obrazowo, system kontroli wersji pozwala nam "upilnować" swój kod. O ile pisząc w pojedynkę małe projekty, system wersjonowania nie przyda się zbytnio, o tyle pisząc coś większego (niezależnie czy samemu czy też w grupie), system kontroli wersji staje się niezbędny.
SVN posiada szereg zalet z których główne to:
Pilnowanie zmian w nazwach plików i katalogów,
Możliwość użycia serwera Apache lub dedykowanego serwera uruchamianego jako inetd albo osobny demon,
Atomowość transakcji, dzięki czemu jesteśmy pewni, że każda zmiana jest zapamiętana w całości i żadna awaria w komunikacji nie jest w stanie zepsuć nam naszej pracy,
Efektywne zarządzaniu repozytorium poprzez stosowanie aliasów, a nie kopiowanie kodu,
Przywracanie dowolnej wersji repozytorium, bądź poszczególnych plików,
Kontrola dostępu do poszczególnych plików (wiadomo kto, kiedy i jakich dokonał zmian),
Możliwość jednoczesnej pracy wielu osób nad różnymi fragmentami kodu, bez ryzyka powstawania konflików.
SVN jest systemem wersjonowania scentralizowanym. Oznacza to że oparty jest on na architekturze klient-serwer, gdzie istnieje jedno repozytorium (źródło kodu) z którym wszyscy użytkownicy systemu synchronizują swoje zmiany. Istnieją także systemy typu P2P lecz nimi w tym artykule zajmować się nie będziemy.
Dlaczego warto używać właśnie SVNa? Oprócz plusów wymienionych parę linijek wyżej, SVN posiada jeszcze jedną bardzo ważną zaletę. Mianowicie jest sprawdzony i popularny. Dzięki temu że jest on popularny, istnieją programy wspomagające korzystanie z tego systemu, zarówno na systemie Linux jak i Windows. Można oczywiście korzystać z SVNa z pomocą wiersza poleceń, lecz na dłuższą metę nie jest to wygodne. Zanim przejdziemy jednak do opisu narzędzi wspomagających, skupmy się może na samym procesie instalacji.
Wymagania wstępne
Aby postawić SVNa i wszystkie związane z nim "bajery", musimy posiadać serwer. Fajnie by było jakby był na Debianie lub Ubuntu, ponieważ proces instalacji opiszę właśnie pod te systemy. Na początek ustalmy sobie co już mamy mieć:
Serwer i prąd
Podłączenie do internetu
Zainstalowany OS (Debian/Ubuntu)
Platformę LAMP (Linux, Apache, MySQL, PHP)
Trochę czasu ;)
Jakie są wymagania względem naszego systemu:
Możliwość zarządzania użytkownikami (prawa dostępu R i RW)
Możliwość tworzenia repozytoriów
Możliwość tworzenia grup użytkowników
Możliwość przeglądania kodu repozytorium z poziomu przeglądarki internetowej
Wszystko co wyżej tylko że wygodnie ;)
Aby osiągnąć powyższe cele, musimy zainstalować i skonfigurować następujące rzeczy:
Subversion
libapache2-svn (dodatek do Apache umożliwiający korzystanie z SVNa)
Submina
WebSVN
Instalacja
Proces instalacji wyżej wymienionych komponentów jest bardzo prosty. Aby zainstalować SVNa, wystarczy wpisać to:
sudo apt-get install subversion
Po tej operacji, mamy już dostęp do obsługi SVNa z linii poleceń. Jednak obsługę wiersza poleceń póki co pominiemy. Zajmijmy się dostępem przez http:
sudo apt-get install libapache2-svn
po instalacji musimy zresetować Apache:
sudo /etc/init.d/apache2 restart
Po tej operacji otrzymamy dostęp do naszych repozytoriów (o ile będą widoczne dla Apache) przez http.
Mając już SVNa i wsparcie dla niego z poziomu Apache, przejdźmy dalej. Zainstalujmy i skonfigurujmy sobie Submina. Submin jest przyjaznym interfejsem do zarządzania SVNem z poziomu przeglądarki internetowej. Umożliwia łatwe tworzenie repozytoriów, grup i użytkowników. Aby go zainstalować, musimy do pliku:
/etc/apt/sources.list
dodać następujące repozytorium oprogramowania:
deb http://debian.supermind.nl/ current main
Następnie aktualizujemy bazę oprogramowania oraz instalujemy submina (po każdej linijce zatwierdzamy naciskając enter):
sudo apt-get update
sudo apt-get install submin
Przy instalacji submina, możemy dostać info że pakiety nie są podpisane. Nie jest to nic groźnego (w tym przypadku), zatwierdzamy więc i kontynuujemy. Po instalacji paczek, musimy jeszcze utworzyć całą konfigurację. Zostanie ona utworzona w katalogu /etc/submin, a tworzymy ją następującym poleceniem:
sudo submin-admin create default
Po wygenerowaniu plików, musimy powiadomić Apache, że ma nowy plik konfiguracyjny do uwzględnienia. Najprościej zrobić to, tworząc link symboliczny:
Obsługa tracka jest wyłączona. W sekcji [generated] klucz będzie wygenerowany automatycznie. Podaję cały plik konfiguracyjny, ponieważ nie pamiętam, które wiersze są generowane domyślnie, a które trzeba dopisać samemu. Po wszystkim resetujemy raz jeszcze Apache:
/etc/init.d/apache2 restart
Teraz wchodzimy pod adres http://adres_naszego_serwera/submin, logujemy się korzystając z domyślnego loginu: admin oraz hasła: admin i korzystamy :)
Pozostało nam zainstalowanie WebSVNa. Służyć on będzie administratorowi do przeglądania wszystkich repozytoriów. Dostęp do niego będzie miał główny administrator, z tego względu skorzystamy z najprostszej metody autoryzacji jaką jest AuthType Basic. Zanim jednak do tego przystąpimy, zainstalujmy WebSVNa:
# To nie jest wymagana - koloruje w websvnie składnię
sudo apt-get install enscript
# To już jest wymagane :)
sudo apt-get install websvn
W czasie instalacji, zostaniemy zapytani o kilka rzeczy. Pierwsze pytanie dotyczyć będzie tego, czy WebSVN ma się skonfigurować:
Akceptujemy konfigurację zaznaczając Yes i naciskając Enter. Na następnym ekranie także naciskamy Enter:
Po zatwierdzeniu przechodzimy do trzeciego ekranu, w którym musimy podać miejsce gdzie znajdują się nasze repozytoria:
W tym miejscu wpisujemy adres, gdzie Submin trzyma repozytoria. W naszym wypadku jest to: /var/lib/submin/svn
Zatwierdzamy naciskając Enter. Następne okno zostawiamy puste. Od tego momentu mamy dostęp do WebSVNa pod adresem: http://adres_naszego_serwera/websvn/.
Po wejściu pod powyższy adres ukaże się nam panel. Póki co mamy z nim dwa problemy:
Wyświetla się nieistniejące repozytorium o nazwie "Repos 1"
System nie pyta ani o login ani o hasło
Rozwiązanie pierwszego problemu opisałem w osobnym poście (link).
Jeśli chodzi o drugi problemy, rozwiązaniem jest dodanie autoryzacji. Z pomocą przyjdzie nam sam Apache. Otwieramy plik /etc/websvn/apache.conf i edytujemy go aby wyglądał tak:
# Configuration for websvn using php4.
Alias /websvn /usr/share/websvn
<Directory /usr/share/websvn>
DirectoryIndex index.php
Options FollowSymLinks
Order allow,deny
allow from all
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user
<IfModule mod_php4.c>
php_flag magic_quotes_gpc Off
php_flag track_vars On
</IfModule>
</Directory>
Włączyliśmy w ten sposób autentykację. Dane do weryfikacji brane są z pliku /etc/apache2/dav_svn.passwd, którego póki co nie ma. Aby go utworzyć przechodzimy do katalogu /etc/apache2/, po czym wydajemy następujące polecenie:
# Podstaw za username własny login
sudo htpasswd -c dav_svn.passwd username
Dostaniemy monit o podanie hasła oraz jego potwierdzenie. Po tym plik zostanie utworzony a my będziemy cieszyć się autoryzacją do naszego WebSVNa.
To by było na tyle. Nie pozostaje nam nic innego jak cieszyć się całkiem sprawnie działającym systemem wersjonowania projektów.