Systemy kontroli wersji

Prezentacja na temat: "Systemy kontroli wersji"— Zapis prezentacji:

1 Systemy kontroli wersji
CVS i SVN

2 Zagadnienia CVS i SVN – charakterystyka i różnice Komendy CVS
Komendy SVN Serwery i ich konfiguracja Aplikacje klienckie Usługi hostingowe

3 CVS - charakterystyka CVS (ang. Concurrent Versions System) to popularny system kontroli wersji udostępniany na licencji GPL. Został stworzony do pracy grupowej nad kodem programów lub innych projektów realizowanych w zapisie elektronicznym. CVS zbudowany jest w architekturze klient/serwer. Dick Grune zaprojektował CVS w latach 80. XX wieku. Od początku lat 90. XX wieku CVS jest wykorzystywany jako narzędzie pracy grupowej w wielu projektach programistycznych, których współpraca opiera się na wykorzystaniu Internetu - m.in. całe systemy operacyjne jak FreeBSD czy NetBSD oraz wielu mniejszych przedsięwzięciach.

4 CVS - charakterystyka Standardowo klient i serwer łączą się ze sobą przez sieć LAN lub przez Internet, istnieje jednak możliwość działania zarówno klienta jak i serwera na jednej maszynie (jeżeli CVS ma za zadanie śledzenie historii wersji projektu wśród developerów lokalnych). Oprogramowanie serwera standardowo obsługiwane jest przez systemy z rodziny Unix, aczkolwiek CVSNT może być uruchomiony także na systemach z rodziny Windows. Oprogramowanie klienckie obsługiwane jest natomiast przez większość dostepnych systemów operacyjnych.

5 CVS - charakterystyka Wszystkie pliki projektu są trzymane w jednym miejscu, w tzw. repozytorium (ang. repository). Użytkownik najpierw pobiera fragment z repozytorium do swojego lokalnego katalogu. Po wprowadzeniu w nim zmian może wysłać poprawki z powrotem do repozytorium, żeby stały się dostępne dla innych. Jeżeli operacja ta zostanie przeprowadzona pomyślnie, kolejne wersje danego projektu są automatycznie inkrementowane przez serwer, który zapisuje datę uaktualnienia wersji oraz informację o autorze w logach. Numery rewizji nadawane są niezależnie dla każdego pliku. Żeby zaznaczyć, że dany zbiór plików w konkretnych rewizjach stanowi wersję pakietu jako całości, albo żeby dla innych potrzeb związać ze sobą rewizje różnych plików, możemy nadać danemu zbiorowi plików o ustalonych rewizjach symboliczną nazwę (tag). Takie nazwy mogą być potem używane zamiast numerów rewizji.

6 CVS - charakterystyka Klient ma możliwość porównywania wersji, oglądania całej historii zmian dokonywanych w projekcie oraz automatycznego uaktualniania swoich plików projektu (likwiduje to konieczność manualnego ściągania aktualnych plików). CVS udostępnia możliwość obsługi autonomicznych gałęzi (ang. branches) danego projektu. Do efektywnego przechowywania wielu wersji jednego pliku używana jest kompresja delta. W środowisku open source CVS był najczęściej wybieranym systemem kontroli wersji dzięki temu, że jest systemem darmowym oraz dzięki swej funkcjonalności i prostocie. CVS jest systematycznie wypierany przez doskonalszy system, którym jest SVN (Subversion).

7 SVN - charakterystyka Subversion (znany również jako SVN) - system kontroli wersji, który powstał w celu zastąpienia CVS. Funkcjonalnie jest z nim zgodny w większości przypadków, z kompatybilności zrezygnowano tylko tam, gdzie było to niezbędne. SVN jest wolnym oprogramowaniem na licencji Apache. SVN został pomyślany jako lepszy CVS. Zachowuje większość koncepcji CVS, zmieniając tylko te, które od początku były uznawane za błędne lub wynikały z zaszłości historycznych. Istnieje jednak sporo różnic między CVS a Subversion.

8 CVS a SVN - różnice wersjonowane są całe projekty
nie ma wersji poszczególnych plików, tylko wersje całego systemu plików do wersji pliku odwołujemy się jako do wersji systemu, w którym plik miał pewną postać wersjonowane są katalogi katalogi można przesuwać (svn move) i usuwać (svn rm) zachowując informacje o ich poprzednim stanie można sprawdzać i odwracać lokalne zmiany bez łączenia się z serwerem operacje takie jak svn status czy svn revert nie wymagają połączenia z serwerem, przez co są o wiele szybsze komenda update działa inaczej svn update uaktualnia pliki w lokalnej kopii i wypisuje informacje tylko o tych plikach, które zostały uaktualnione svn status wypisuje pliki, które zostały lokalnie zmienione (chyba, że poda mu się flagę -u)

9 CVS a SVN - różnice branchowanie i tagowanie jest szybkie i przejrzyste dla Subversion tag jest kopią danych z osobnego katalogu w repozytorium SVN tworzy kopie plików w sposób efektywny czasowo i pamięciowo SVN pamięta własności plików i katalogów, oprócz ich fizycznej zawartości SVN wymaga rozwiązania explicit konfliktów pojawiających się podczas uaktualniania wersji SVN efektywnie traktuje pliki binarne SVN umożliwia dostęp do repozytorium na wiele sposobów demon svnserve tunelowanie połączenia w dowolny sposób (svn+ssh, svn+rsh itd.) moduł Apache (SSL lub HTTP) zmiany są transakcjami atomowymi zmiany w kilku plikach lub katalogach odnoszą skutek tylko wtedy, gdy wszystkie modyfikacje zostały zakończone pomyślnie

10 Komendy cvs 1. Składnia: cvs [-opcje_ogólne] polecenie [-opcje_polecenia][argumenty] Przydatne opcje: -n pusty przebieg, żadnych efektów -t wyświetla komunikaty pokazujące etapy pracy cvs

11 Komendy cvs 2. Łączenie się z serwerem CVS:
Ustawienie zmiennej środowiskowej CVSROOT: Połączenie do lokalnego serwera CVS export CVSROOT=/var/cvsroot Zdalny serwer CVSROOT używający protokołu haseł serwera CVS: export CVSROOT z RSH/SSH export

12 Komendy cvs Jeżeli zmienna środowiskowa CVS_RSH ma wartość "ssh" to nasz klient będzie się starał użyć ssh do nawiązania połączenia. W innym przypadku użyje RSH. Połączenie RSH/SSH jest bezpieczne, jednak nie umożliwia pobierania źródeł przez klienta anonimowego. Jeżeli nie ustawimy zmiennej CVSROOT, polecenia: cvs login cvs checkout będą wymagały dodatkowo dopisania: -d po komendzie cvs. Eksportowanie zmiennej CVSROOT przyspiesza pracę.

13 Komendy cvs 3. Logowanie do serwera: cvs login|logon|lgn Brak ustawionej zmiennej CVSROOT: cvs –d login Następnie podajemy nasze hasło. W przypadku logowania się na konto anonimowe nie podajemy nic.

14 Komendy cvs 4. Pobieranie repozytorium:
cvs checkout|co|get [-ANPRcflnps] [-r rev] [-D date] [-d dir] [-j rev1] [-j rev2] [-k kopt] modules... Dostępne opcje: -c - wyświetla listę modułów dostępnych w repozytorium (o ile administrator uaktualnił bazę danych modułów) -d nowy_katalog - zapisuje moduł do katalogu 'nowy_katalog' -z<0-9> - poziom kompresji Więcej informacji: cvs –help co

15 Komendy cvs Kiedy komenda wypożyczenia ("co") wykona swoje zadanie, ujrzymy katalog "moduły" w katalogu, w którym obecnie się znajdujemy; przechowywane będą tam najnowsze zasoby. Zauważyć można, że wszystkie katalogi mają dodatkowy katalog CVS znajdujący się wewnątrz nich - w ten właśnie sposób CVS przechowuje informacje dotyczące konta użytkownika. Owe katalogi można spokojnie pominąć i zapomnieć o nich. Odtąd nie będziemy musieli się martwić ustawianiem zmiennej CVSROOT, czy też przymusem wpisywania wartości CVSROOT w linii poleceń. Dzieje się to dlatego, że te dane są zapisane właśnie we wcześniej wspomnianych katalogach. Ustawienie zmiennej CVSROOT jest wymagane tylko przy początkowej inicjalizacji oraz wykonywaniu polecenia "co". Również opcja export|ex|exp.

16 Komendy cvs 5. Aktualizacja zasobów:
cvs update|up|upd [-APCdflRp] [-k kopt] [-r rev] [-D date] [-j rev] Powoduje połączenie najnowszej wersji plików z repozytorium z plikami pobranymi wcześniej przez nas. W efekcie nasze lokalne pliki będą zawierać wszystkie wprowadzone do tej pory zmiany. Konieczne jest wydanie tej komendy w przypadku, gdy CVS wykryje konflikt wersji. Przykład: cvs up –dP -d – stwórz nowe katalogi, jeśli te wystąpiły w repozytorium -P – usuń puste katalogi z lokalnie wypożyczonych kopii plików. Używanie "-P" to naprawdę dobry pomysł ponieważ cvs ma skłonność do tworzenia dużej liczby pustych (użytych raz, a następnie porzuconych) gałęzi drzewa. -C modyfikowany_plik – cofnięcie zmian w pliku, nadpisuje lokalnie zmodyfikowaną kopię pliku najnowszą rewizją z repozytorium -r Więcej informacji: cvs –help up

17 Komendy cvs 6. Zatwierdzanie zmian: Przykład:
cvs commit|ci|com [-Rlf] [-m msg | -F logfile] [-r rev] files... Przykład: cvs commit plik.cpp cvs commit directory cvs commit –m “nasz komentarz” cvs commit –r 3.0 "cvs commit" nie tylko zatwierdza nasze zmiany w repozytorium, ale zanim prześle je do zdalnego repozytorium, cvs uruchomi domyślny edytor i pozwoli na krótkie opisanie modyfikacji, które wprowadzamy. Po wprowadzeniu komentarzy, zapisaniu pliku i wyjściu z edytora, nasze zmiany zostaną wprowadzone w zdalnym repozytorium i będą dostępne dla wszystkich deweloperów w zespole. CVS ściągnął i poprawnie połączył zmiany. Niestety CVS to nie człowiek, więc nie potrafi myśleć i dlatego nie zawsze uda mu się automatycznie połączyć zmiany. W takiej sytuacji zasygnalizuje błąd ,,conflicts during merge”. Dokończenia łączenia będzie musiał dokonać człowiek.

18 Komendy cvs Podczas aktualizacji danych serwer informuje nas o statusie plików, z którymi miał do czynienia podczas przeprowadzania aktualizacji. Możliwe są następujące litery statusu: - U serwer przesłał nam kompletny plik z repozytorium - P serwer przesłał nam jedynie różnicę (diff) pomiędzy plikiem w repozytorium a naszym lokalnym - A plik został dodany do lokalnej kopii ale informacja o tym nie została przesłana do repozytorium (nie wykonano komendy commit) - R plik został usunięty z lokalnej kopii ale informacja o tym nie - M kopia lokalna pliku został zmieniona - C podczas próby automatycznego łączenia został wykryty konflikt - ? plik istnieje tylko w lokalnej kopii i nie posiada odpowiednika w repozytorium Możemy nakazać CVS’owi ignorować określone pliki. Wystarczy wpisać nazwy plików do pliku ,,.cvsignore” i przesłać ów plik do repozytorium. Więcej informacji: cvs –help commit

19 Komendy cvs 7. Przeglądanie dziennika: cvs log|lo|rlog [-lRhtNb] [-r[revisions]] [-d dates] [-s states] [files…] Pozwala obejrzeć historię wpisów dokonywanych przy przesyłaniu poprawek (commit -m xyz). Więcej informacji: cvs –help log

20 Komendy cvs 8. Dodawanie pliku/katalogu do repozytorium
cvs add|ad|new [-k rcs-kflag] [-m message] files... Przykład: cvs add plik.c mkdir katalog cvs add katalog Dodanie pliku do repozytorium następnym razem gdy użyjemy komendy cvs commit - inni deweloperzy będą mogli zobaczyć ten plik.

21 Komendy cvs Inaczej niż w przypadku dodawania pliku, katalog pojawia się w repozytorium od razu. Nie jest potrzebny cvs commit. Kiedy już dodamy lokalny katalog do cvs, wewnątrz niego zostanie utworzony kolejny katalog, tym razem o nazwie "CVS", służący do przechowywania danych o koncie użytkownika. W ten sposób wystarczy spojrzeć do określonego katalogu, a w nim znaleźć CVS by wiedzieć, że ten katalog został dodany do repozytorium. Więcej informacji: cvs –help add

22 Komendy cvs 9. Usuwanie pliku: cvs remove|rm|delete [-flR] [files...] Plik zostanie zaplanowany do usunięcia z repozytorium następnym razem gdy zatwierdzimy zmiany. Kiedy zatwierdzimy plik, zostanie on oficjalnie usunięty z lokalnej wersji repozytorium. Chociaż cvs nie usunie tego pliku i będzie przechowywał całkowity stan jego zawartości i historii, jeśli pojawi się potrzeba jego przejrzenia później. Jest to jeden ze sposobów w których cvs chroni wartościowy kod źródłowy. cvs remove jest komendą rekursywną, co oznacza, że możemy usunąć kilka plików, a potem zastosować cvs remove (komendę) bez żadnych argumentów z macierzystego katalogu. Czyniąc to sprawimy, że wszystkie usunięte pliki będą oznaczone jako usunięte, co zostanie wykonane przy następnym zatwierdzeniu zmian.

23 Komendy cvs Możemy nakazać CVSowi ignorować określone pliki. Wystarczy wpisać nazwy plików do pliku ,,.cvsignore” i przesłać ów plik do repozytorium. Przykład: cvs remove plik.cpp cvs remove mój_katalog cvs remove -f plik.cpp – usuwa plik fizycznie Więcej informacji: cvs –help remove

24 Komendy cvs 10. Status cvs status|st|stat [-vlR] [files...] Otrzymamy informacje o numerze rewizji, lokalizacji pliku w repozytorium, oznakowaniu pliku (nazwami symbolicznymi) itp. Najistotniejsze dla nas jest pole ,,Status:”. Plik może mieć jeden z poniższych statusów: - Up-to-date - plik jest aktualny (identyczny z wersją w repozytorium) - Locally Modified - lokalna kopia pliku została zmieniona - Locally Added - plik został dodany do lokalnej kopii - Locally Removed - plik został usunięty z lokalnej kopii - Needs Checkout - ktoś dokonał zmian w pliku i przesłał

25 Komendy cvs - Needs Patch zmiany do repozytorium. Należy wykonać update. - Needs Merge - wymagane jest połączenie naszych zmian w pliku ze zmianami innej osoby - File had conflicts on merge - podczas łączenia wystąpiły konflikty - Unknown - plik istnieje tylko w lokalnej kopii i nie posiada odpowiednika w repozytorium Przykład: cvs status -v plik.cpp Więcej informacji: cvs –help status

26 Komendy cvs 11. Anulowanie komendy checkout: release [-d] directories... Służy do anulowania komendy checkout bez zapisywania zmian. Dodatkowo możemy usunąć katalog lokalny korzystając z opcji –d. Po zakończeniu lokalnych działań nad projektem nie jest wskazane kasowanie jego katalogu, należy zwolnić go poleceniem cvs release. Zakończenie sesji. Przykład: cvs release nazwa_katalogu Więcej informacji: cvs –help release

27 Komendy cvs 12. Utworzenie etykiety symbolicznej (rozgałęzienie):
cvs tag|ta|freeze [-bcdFflR] [-r rev|-D date] nazwa_symboliczna [files...] CVS nadaje numery wersji indywidualnie dla każdego pliku. Czasami jednak chcemy zaznaczyć, że kilka plików należy do tego samego wydania. Inną możliwą sytuacją jest potrzeba rozwijania projektu „wielowątkowo”, tzn. zmiany w projekcie mogą iść w dwóch różnych kierunkach, a my chcemy zachować nad nimi kontrole. Służą do tego właśnie znaczniki. Dzięki nim możemy oznaczyć kilka plików jako konkretne wydanie, lub tez stworzyć „odgałęzienia”(branches). Przykład: cvs tag –c version-3 cvs checkout –r version-3 test – pobranie plików z przypisaną etykietą Więcej informacji: cvs –help tag

28 Komendy cvs 13. Usunięcie etykiety symbolicznej: cvs rtag|rt|rfreeze [-abdFflnR] [-r rev|-D date] tag modules... Przykład: cvs rtag –d version-3 Więcej informacji: cvs –help rtag

29 Komendy cvs 14. Informacje dotyczące modyfikacji danego pliku: cvs annotate|ann [-lRfF] [-r rev] [-D date] [files...] Wyświetla informacje o ostatnich modyfikacjach w każdej linii pliku.

30 Komendy cvs Przykład: annotate example1 Annotations for example1/header.h *************** 1.1 (marek 01-Oct-08):#define NAME "MAREK" Annotations for example1/test.c 1.1(marek 01-Oct-08): #include <stdio.h> 1.4(marek 01-Oct-08): #include "header.h" 1.1(marek 01-Oct-08): 1.1(marek 01-Oct-08): int main(){ 1.5(anonymous 02-Oct-03): printf ("Witaj swiecie\n"); 1.4(marek 01-Oct-03): printf ("%s\n", NAME); 1.1(marek 01-Oct-03): return 0; 1.1(marek 01-Oct-03): } Więcej informacji: cvs –help ann

31 Komendy cvs 15. Różnica pomiędzy wersjami pliku: cvs diff [-lR] [-k kopt] [format_options] Opcja ,,-r” pozwala na porównywanie wg. numerów rewizji. Możliwe jest także porównywanie wg. daty (opcja ,,-D”) jak i mieszane. cvs diff -u plik - wyświetla różnicę pomiędzy najnowszą rewizją pliku z repozytorium, a plikiem znajdującym się katalogu roboczym cvs diff -u -r1.1 plik - wyświetla różnicę pomiędzy rewizją 1.1, a plikiem znajdującym się aktualnie w katalogu roboczym cvs diff -u -r1.1 -r1.3 plik - wyświetla różnicę pomiędzy rewizją 1.1, a 1.3

32 Komendy cvs Przykład: cvs diff -u -r1.2 -r1.3 plik.c cvs diff -u -r1.2 -Dnow plik.c cvs diff -u -D’1 minute ago’ -Dnow plik.c vs diff -u -D’ ′ -Dnow plik.c Więcej informacji: cvs –help diff

33 Komendy cvs 16. Różnica pomiędzy wersjami repozytorium: cvs rdiff|patch|pa [-flR] [-c|-u] [-s|-t] [-V %d] [-k kopt] Wyświetla różnice między dwoma wersjami modułu. Przykład: cvs rdiff -r rev1 -r rev2 target Więcej informacji: cvs –help rdiff

34 Komendy cvs 17. Tworzenie nowego archiwum: cvs import|im|imp [-d] [-k subst] [-I ign] [-m msg] [-b branch] [- W spec] repository vendor-tag release-tags... Tworzy nowy moduł w repozytorium Przykład: svn import twój-projekt \ nazwa-projektu -m "początkowy import projektu" Tworzy katalog o nazwie nazwa-projektu w Twoim repozytorium. Katalog ten zawiera pliki Twojego projektu.

35 Komendy cvs cvs import -m "Komentarz" module-name vendor- tag release-tag module-name – nazwa modułu – jest nazwą katalogu w którym będzie przechowywany nasz projekt, tą nazwą będziemy się posługiwali chcąc ściągnąć projekt do naszego lokalnego katalogu vendor-tag – nazwa opiekuna - nazwa osoby dodającej moduł do repozytorium release-tag – nazwa wydania - nazwa wydania, może być np. start Więcej informacji: cvs –help import

36 Komendy cvs 18. Historia: cvs history|hi|his [-report] [-flags] [-options args] [files...] Pokazuje historie dostępu do repozytorium Więcej informacji: cvs –help history.

37 Komendy cvs 19. Usuwanie danych dotyczących logowania: cvs logout Usuwa .cvspass z lokalnego repozytorium. Więcej informacji: cvs –help logout

38 Komendy cvs 20. Informacje dotyczące modułu: cvs rlog Więcej informacji: cvs –help rlog

39 Komendy cvs 21. Informacje o aktualnej wersji repozytorium cvs version Więcej informacji: cvs –help version

40 Komendy cvs 22. Kto przegląda pliki: cvs watches Więcej informacji: cvs –help watches

41 Komendy cvs 23. Zarządzanie repozytorium: cvs admin|adm|rcs [options] files... Więcej informacji: cvs –help admin

42 Komendy cvs 24. Tworzenie repozytorium: cvs -d "$HOME/cvsroot" init
cvs -d "$HOME/cvsroot" init Utworzenie nowego repozytorium w katalogu domowym użytkownika, w podkatalogu cvsroot. Więcej informacji: cvs –help init W repozytorium najczęściej składowane są pliki tekstowe. Pliki binarne z reguły są generowane automatyczne, a nie pisane przez człowieka, i nie stanowią części źródeł. Również porównywanie wersji plików binarnych i nakładanie poprawek rzadko ma inny sens niż stwierdzenie ,,takie same'' albo ,,różne'' oraz zastąpienie nową wersją. Mimo wszystko w CVSie można umieszczać też pliki binarne. Należy wtedy używać opcji -kb, która wyłącza tłumaczenie końców linii z lokalnego standardu na konwencję stosowaną w CVSie (w przypadku Unixa nie ma to akurat znaczenia) oraz zastępowanie słów kluczowych.

43 Komendy SVN 1. Tworzenie repozytorium: svnadmin create --fs-type fsfs REPOS_PATH Tworzy nowe, puste repozytorium typu FSFS w podanej lokalizacji. Lokalizacja musi być lokalną ścieżką, a nie adresem URL.

44 Komendy SVN 2. Importowanie projektu: svn import [PATH] URL Importuje projekt o ścieżce `PATH` do repozytorium pod wskazanym `URL`. Jeśli parametr PATH nie jest określony, ścieżka aktualnego katalogu zostanie użyta. Ważne parametry: -m TEXT opis modyfikacji. Jeśli brakuje modyfikatora domyślny edytor($SVN_EDITOR ) zostanie uruchomiony w celu wpisania opisu modyfikacji.

45 Komendy SVN 3. Checkout projektu: svn checkout URL [PATH] Kopiuje pliki z repozytorium do wskazanego katalogu bądź do bieżącego jeśli parametr ‘PATH’ nie został użyty. Polecenie oprócz skopiowania plików projektu tworzy specjalny folder .SVN, dzięki któremu nie będziemy musieli wpisywać ścieżki repozytorium następnym razem.

46 Komendy SVN 4. Aktualizacja projektu: svn update [PATH...]
svn update [PATH...] Polecenie zawsze wykonujemy przed rozpoczęciem pracy z projektem. Pobiera ona wszystkie zmiany z repozytorium i modyfikuje nasz lokalny projekt. Po wykonaniu polecenia, wszystkie zmiany będą wyświetlone z odpowiednim znakiem: A - Plik dodany D – Plik usunięty U – Plik zaktualizowany C - Konflikt G – Plik scalony Ważne parametry:  --revision (-r) – numer wersji. Jeśli parametr nie zostanie użyty, najnowsza wersja będzie brana pod uwagę.

47 Komendy SVN 5. Status lokalny: svn status [PATH...]
svn status [PATH...] Wyświetla status katalogu roboczego(lokalnego). Komenda sprawdza status lokalny i dlatego nie musi łączyć się z repozytorium. Każda wyświetlona linia poprzedzona jest jednym z następujących znaków: 'A' - Plik dodany 'D' - Plik usuniętny 'M' –Plik zmodyfikowany 'C' – Występuje konflikt '?' – Plik występuje w katalogu roboczym ale nie jest pod kontrolą wersji. `!` - Brak pliku. Prawdopodobnie plik został usunięty za pomocą innych narzędzi niż SVN.

48 Komendy SVN 6. Aktualizacja repozytorium (commit):
svn commit [PATH...] Zatwierdza i wysyła wszystkie zmiany do repozytorium. Aby sprawdzić, które pliki zostaną zmienione należy skorzystać z polecenia SVN status. Ważne parametry: -m TEXT opis modyfikacji. Jeśli brakuje modyfikatora domyślny edytor($SVN_EDITOR ) zostanie uruchomiony w celu wpisania opisu modyfikacji.

49 Komendy SVN 7. Dodawanie plików lub folderów do katalogu roboczego:
svn add PATH... Dodaje pliki lub foldery do katalogu roboczego. Przydatna komenda gdy stworzymy jakiś plik w obcym narzędziu a następnie skopiujemy go do katalogu roboczego innym narzędziem niż SVN. Wtedy po wykonaniu polecenia ‘svn status ’ plik będzie opatrzony znakiem `?`. Znak ‘?’ informuje nas, że plik nie jest pod kontrolą wersji SVN. Abyśmy mogli potwierdzać zmiany(SVN commit) musimy go najpierw dodać do systemu kontroli wersji za pomocą komendy `svn add`. Zatem wszystkie nowe pliki\foldery, które stworzymy musimy dodawać za pomocą `svn add` a nie za pomocą zwykłego kopiowania plików.

50 Komendy SVN 8. Usuwanie plików lub folderów z katalogu roboczego:
svn delete PATH... svn delete URL... Komenda analogiczna do svn add. Gdy plik został usunięty innym narzędziem niż SVN to po wykonaniu komendy `svn status` taki plik będzie opatrzony znakiem `!` informującym, że plik fizycznie nie istnieje a jednak w systemie SVN jest zapisany jako plik pod kontrolą wersji. Musimy więc poinformować SVN, żeby usunął go ze swojej pamięci za pomocą komendy `SVN delete.` Druga wersja komendy usuwa plik bezpośrednio z repozytorium wykonując od razu `SVN commit`.

51 Komendy SVN 9. Wycofywanie zmian lokalnych: svn revert PATH.
svn revert PATH. Wycofuje wszystkie zmiany wprowadzone lokalnie, które można zobaczyć za pomocą komendy `SVN STATUS`. Ważne parametry --recursive - rekurencyjne odwracanie zmian. Przydatne gdy chcemy wycofać zmiany dla całego katalogu.

52 Komendy SVN 10. Właściwość PROPNAME:
svn propset PROPNAME [PROPVAL | -F VALFILE] PATH Ustawia właściwość o nazwie `PROPNAME` na podaną wartość(`PROPVAL`) dla wskazanego pliku lub katalogu. W środowisko SVN mamy wiele właściwości, które mogą przybierać różne wartości. Jedną z właściwości jest SVN:IGNORE, która informuje system, że wskazany katalog\plik będzie ignorowany przez SVN.W praktyce, często korzystamy z tej właściwości aby wszelkie pliki tymczasowe(logi, cache itp.) były ignorowane (nie wysyłane) przez svn w celu zaoszczędzenia miejsca oraz przyspieszenia wysyłania.

53 Komendy SVN Przykład 1: > svn propset svn:ignore ‘*’ c:\projektA\projekt1\tmp Od tego momentu zawartośc katalogu tmp będzie ignorowana przez SVN. Przykład 2: > svn propset svn:ignore –F ignore.txt c:\projektA\projekt1\tmp W pliku ignore.txt należy umieścić listę reguł.

54 Komendy SVN 11. Domyślny edytor tekstu: svn propedit PROPNAME PATH...
svn propedit PROPNAME PATH... Uruchamia domyślny edytor tekstu i pozwala na wprowadzenie reguł filtrowania.

55 Komendy SVN 12. Wyświetlanie właściwości katalogu:
svn proplist [PATH...] Wyświetla wszystkie właściwości skojarzone z bieżącym lub wskazanym katalogiem.

56 Komendy SVN 13. Wyświetlanie właściwości katalogu:
svn propget PROPNAME [PATH...] Wyświetla wartość podanej właściwości na podanym lub bieżącym katalogu.

57 Komendy SVN 14. Komendy wirutalnego systemu plików: svn ls svn mkdir
svn ls svn mkdir svn move Komendy działają na wirtualnym systemie plików SVN. Dzięki temu po stworzeniu np. folderu nie musimy go dodawać za pomocą `svn add` do systemu kontroli wersji.

58 Komendy SVN 15. Wyświetlanie różnic między plikami:
svn diff [-r N[:M]] [--old OLD-TGT] [--new NEW-TGT] [PATH...] svn diff -r N:M URL svn diff [-r N[:M]] Wyświetla różnice między plikami. Aby określić która wersje(revision) chcemy brać pod uwagę należy użyć parametru –r. Jeśli nie dostarczymy parametrów domyślnie będą pokazywane różnice pomiędzy wszystkimi plikami lokalnymi a tymi z repozytorium.

59 Komendy SVN Przykłady: Pokazuje różnice pomiędzy plikami w „revision” 3000 a $svn diff lub $svn diff -r 3000: Pokazuje różnice dokonane na pliku 1.txt pomiędzy wersjami 17 a 18. $ svn diff -r 17:18 1.txt

60 Komendy SVN 16. Wyświetlanie informacji dla wskazanej ścieżki:
svn info [PATH] Wyświetla informacje dla wskazanej ścieżki. np : - numer „revision” - nazwę osoby, która ostatnio dokonała zmiany - datę ostatniej modyfikacji - ścieżkę do repozytorium

61 Komendy SVN 17. Konflikty:
Po aktualizacji przez użytkownika A nastąpi konflikt ponieważ użytkownik B nie będzie mógł wykonać poprawnie operacji update. plik.mine – plik użytkownika B sprzed wykonania operacji update. plik.rOLDREV – plik sprzed wykonania svn commit przez użytkownika A. plik.rNEWREV – aktualna wersja w repozytorium(wersja użytkownika A) Plik oryginalny Zmiany A Zmiany B 1 2 3 4 5

62 Komendy SVN 18. Rozgałęzienia:
Cel - utrzymanie kilku wersji produktów bądź kilku projektów o różnym statusie(release,debug). svn copy file:///c:/rep/project file:///c:/rep/project_1.xxx Kopiowanie jest bardzo wydajnie gdyż polega one tylko na stworzeniu dowiązania. Fizycznie w bazie projekt nie jest kopiowany a zatem zaoszczędzamy miejsce. Zmiany na dowiązaniu i korzeniu nie wpływają na siebie(są to niezależne fragmentu projektu).

63 Komendy SVN 19. Checkout gałęzi:
Po skopiowaniu możemy pracować z rozgałęzieniem tak jak z podstawową wersją projektu. Dla przykładu aby wykonać „checkout” należy wpisać: svn checkout file:///c:/rep/project_1.xxx

64 Komendy SVN 20. Przełączanie gałęzi:
svn switch file:///c:/rep/project1 Komenda przełącza nas do wskazanej gałęzi co oznacza, że aktualny folder roboczy zostanie zaktualizowany danymi z określonej gałęzi.

65 Komendy SVN 21. Scalanie gałęzi: svn merge -r N:M SOURCE [PATH]
svn merge -r N:M SOURCE [PATH] Komenda służąca do scalania dwóch gałęzi. Dla przykładu aby scalić aktualna gałąź(projektxxx) z projekt1 należy svn merge file:///c:/rep/projekt1 Można także określić wersje które mają być brane pod uwagę za pomocą parametru –r.

66 SERWERY CVS SVN W teorii SVN może korzystać z nieograniczonej liczby implementacji sieci. W praktyce obecnie dostępne są tylko dwa serwery: Apache i svnserve. Apache jest bardzo popularnym Web serwerem używającym modułu mod_dav_svn, może łączyć się z repozytorium i udostępniać je klientom przez protokół WebDAV/DeltaV, który jest rozszerzeniem HTTP. Apache udostępnia wiele opcji za darmo np. szyfrowaną komunikacje SSL, logowanie, integracje z systemami autentykacji i ograniczony web browsing repozytorium.

67 SERWERY CVS Svnserve jest małym serwerem z protokołem stworzonym przede wszystkim dla SVN, operacje sieciowe wykonywane sa szybciej ale kosztem innych opcji. Svnserve może korzystać z SASL do autentykacji i szyfrowania, nie posiada logowania i web browsingu. Jest bardzo prosty do konfiguracji i często jest najlepszą opcją dla grup zaczynających przygodę z SVN. Trzecia opcją jest użycie svnserve przez polaczenie tunelowane SSH. Chociaż opcja ta nadal korzysta z svnserve różni się od tradycyjnej opcji svnserve. SSH jest używany do szyfrowania wszystkich połączeń oraz do autentykacji.

68 SERWERY CVS SVNSERVE serwer Zalety: - Szybki i łatwy w konfiguracji. - Protokół sieciowy jest szybszy niż WebDAV. - Nie wymaga tworzenia kont systemowych na serwerze. - Hasło nie jest przesyłane przez siec. Wady: - Domyślnie dostępna jest tylko jedna metoda autentykacji, protokół sieciowy nie jest szyfrowany, serwer przechowuje hasła w postaci czystego tekstu. (Wszystkie te opcje można zmienić konfigurując SASL, lecz wymaga to trochę pracy.) - Nie ma logowania. - Nie ma web browsingu.

69 SERWERY CVS SVNSERVE przez SSH Zalety: - Protokół sieciowy szybszy niż WebDAV. - Można wykorzystać istniejące konta SSH i infrastruktóre użytkowników. - Cały ruch sieciowy jest szyfrowany. Wady: - Dostępna jest tylko jedna metoda autentykacji. - Nie ma logowania. - Wymaga aby użytkownicy byli w tej samej grupie systemowej lub używali współdzielonego klucza SSH.

70 SERWERY CVS Apache http serwer Zalety: - Pozwala na korzystanie z wielu metod autentykacji. - Nie trzeba tworzyć kont na serwerze. - Dostępne jest logowanie. - Ruch sieciowy może być szyfrowany przez SSL. - Web browsing repozytorium dostępne jest przez przeglądarkę sieciowa. - Repozytorium może być zamontowane jako dysk sieciowy. Wady: - Wolniejszy od svnserve - Pierwsza konfiguracja może być skomplikowana.

71 KONFIGURACJA SERWERÓW
SVNSERVE: Jest kilka metod na uruchomienie svnserve: Svnserve jako daemon $ svnserve -d $ # svnserve is now running, listening on port 3690 W celu zwiększenia bezpieczeństwa można użyć opcji –r która pozwala na export repozytoriów znajdujących się wyłącznie po podana ścieżka. $ svnserve -d -r /var/svn …

72 KONFIGURACJA SERWERÓW
Start serwera: $ svnserve –i Konfiguracja: (w pozostałych przypadkach wyglada podobnie) Do pliku /etc/services dopisujemy lub odkomentowujemy: svn 3690/tcp #Subversion svn 3690/udp #Subversion Do pliku /etc/inetd.conf dopisujemy lub odkomentowujemy: # SVN svnserve svn stream tcp nowait svnroot /usr/bin/svnserve svnserve -i

73 KONFIGURACJA SERWERÓW
Należy jeszcze ustawić dostęp w plikach konfiguracyjnych repozytorium: conf/svnserve.conf [general] anon-access = read auth-access = write password-db = passwd realm = Moje repozytorium Dyrektywa password-db oznacza nazwę pliku haseł conf/passwd [users] user1=haslo_plaintext1 user2=haslo_plaintext2

74 KONFIGURACJA SERWERÓW
Po restarcie demona inetd możemy łączyć się z repozytorium podając svn://serwer/sciezka/do/repozytorium zamiast file:///sciezka/do/repozytorium SVNSERVE jako Windows service C:\> sc create svn binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos" displayname= "Subversion Server" depend= Tcpip start= auto

75 KONFIGURACJA SERWERÓW
APACHE: Konfiguracja Subversion: Na początku tworzymy katalog, w którym znajdować się będą nasze repozytoria SVN. Przykładowo: mkdir -p /home/subversion/public W omawianym przypadku publicznie dostępne repozytoria będziemy przechowywać w katalogu /home/subversion/public. Oczywiście to tylko przykład. Katalog może równie dobrze znajdować się w /var/lib czy też bezpośrednio w głównym węźle plików. Kolejny krok to założenie pierwszego repozytorium. W naszym przypadku będzie to repozytorium ‘faq’. Komenda zakładająca nowe repozytorium o nazwie ‘faq’ to: svnadmin create faq W tym momencie Subversion mamy już wstępnie skonfigurowane. Pora na Apache.

76 KONFIGURACJA SERWERÓW
Konfiguracja Apache 2: Kolejnym, bardzo istotnym krokiem jest konfiguracja serwera Apache. Będziemy musieli wygenerować certyfikat oraz zmodyfikować kilka plików konfiguracyjnych, a także stworzyć użytkowników Subversion i określić ich prawa. Generujemy certyfikat SSL: Subversion wykorzystuje uwierzytelnianie SSL dostarczone przez Apache 2. Aby z niej skorzystać, musimy wygenerować certyfikat SSL poleceniem: apache2-ssl-certificate

77 KONFIGURACJA SERWERÓW
Przy zakładaniu certyfikatu konfigurator pyta nas o kilka informacji, takich jak: kod państwa, nazwa miejscowości, czy organizacja wystawiająca certyfikat. Wymagana do założenia certyfikatu jest jedynie nazwa serwera (w naszym przypadku: foka). Certyfikat po wygenerowaniu zapisze nam się zapewne do pliku /etc/apache2/ssl/apache.pem. Jeśli jest inaczej, zapiszmy sobie ścieżkę. Będzie potrzebna już niedługo. Uwaga: ta metoda generowania certyfikatu może spowodować błąd. Po kolei wykonujemy w takim przypadku polecenia: openssl req -new > new.cert.csr openssl rsa -in privkey.pem -out new.cert.key SSLCertificateFile /etc/pki/tls/certs/new.cert.cert SSLCertificateKeyFile /etc/pki/tls/private/new.cert.key

78 KONFIGURACJA SERWERÓW
Uaktywniamy obsługę SSL w Apache: Aby uaktywnić obsługę SSL w Apache 2 musimy po pierwsze dodać w pliku /etc/apache2/ports.conf linijkę Listen 443 To spowoduje, że nasz serwer zacznie nasłuchiwać również na porcie 443 (domyślny port SSL). Następnie musimy stworzyć w katalogu /etc/apache2/mods-enabled/ linki do plików ssl.conf i ssl.load z /etc/apache2/mods-available ln -s /etc/apache2/mods-available/ssl.load \ /etc/apache2/mods-enabled/ ln -s /etc/apache2/mods-available/ssl.conf \ dzięki czemu moduły odpowiadające za obsługę SSL zostaną załadowane przy starcie Apache.

79 KONFIGURACJA SERWERÓW
Uaktywniamy obsługę Subversion w Apache: Aby uaktywnić obsługę Subversion w Apache 2 musimy, podobnie jak to było z SSL, stworzyć w katalogu /etc/apache2/mods-enabled/ link do pliku dav_svn.load z /etc/apache2/mods-available: ln -s /etc/apache2/mods-available/dav_svn.load \ /etc/apache2/mods-enabled/ Moduły odpowiadające za obsługę Subversion zostaną załadowane przy starcie Apache, razem z innymi modułami Apache.

80 KONFIGURACJA SERWERÓW
Konfigurujemy wirtualnego hosta: W kolejnym kroku tworzymy plik /etc/apache2/sites-available/subversion. Przykładowa konfiguracja, wraz z opisem istotnych linijek poniżej: # Adres IP i port - najczęściej będzie to adres komputera, #na którym stawiamy serwer oraz port 443 (SSL) # W tym przypadku adres IP należy do sieci wewnętrznej, # ponieważ mój serwer SVN działa właśnie w takiej sieci, # a na zewnątrz udostępniany jest poprzez przekierowanie # portu 443 # na sprzętowym firewallu. <VirtualHost :443> # Administrator serwera SVN ServerAdmin # Nazwa serwera (np. nazwa komputera) ServerName foka # Uaktywniamy SSL

81 KONFIGURACJA SERWERÓW
SSLEngine On # Podajemy lokalizację wygenerowanego pliku z certyfikatem SSLCertificateFile /etc/apache2/ssl/apache.pem # Konfigurujemy publiczny katalog do # przeglądania repozytorium <Location /public> # Uprawnienia do katalogu - ustawiamy dostęp ze # wszystkich adresów Order allow,deny Allow from all # Każemy użyć modułu svn_dav zamiast zwykłego webdav DAV svn # ścieżka do nadrzędnego katalogu z repozytoriami SVNParentPath /home/subversion/public # ścieżka do pliku z definicją uprawnień dostępu # dla użytkowników i grup AuthzSVNAccessFile \ /etc/apache2/auth-files/public-svn-authzfile # Używamy metody HTTP Basic Authentication Satisfy Any Require valid-user

82 KONFIGURACJA SERWERÓW
AuthType Basic # Tekst pojawiający się w okienku logowania Apache AuthName "example.org Subversion Repository" # Lokalizacja pliku z zaszyfrowanymi hasłami użytkowników SVN AuthUserFile /home/subversion/.dav_svn.passwd </Location> # Określamy poziom logowania i pliku logów ErrorLog /var/log/apache2/error.log LogLevel warn CustomLog /var/log/apache2/access.log combined </VirtualHost> Bardzo istotne w tej konfiguracji są linijki: AuthzSVNAccessFile /etc/apache2/auth-files/public-svn-authzfile

83 KONFIGURACJA SERWERÓW
Aby uaktywnić konfigurację, musimy stworzyć wspomniane dwa pliki (o tym poniżej), a następnie utworzyć linki symboliczne do katalogu /etc/apache2/sites-enabled: ln -s /etc/apache2/sites-available/subversion \ /etc/apache2/sites-enabled/ Uwaga: Jeśli wygenerowaliśmy klucze poleceniem openssl, należy zamiast jednego pliku z certyfikatem podać dwa, np. w taki sposób: SSLCertificateFile /etc/pki/tls/certs/new.cert.cert SSLCertificateKeyFile /etc/pki/tls/private/new.cert.key

84 KONFIGURACJA SERWERÓW
Konfigurujemy uprawnienia dostępu do repozytoriów: Aby korzystać z SVN musimy stworzyć użytkowników posiadających uprawnienia do ściągania bądź modyfikacji danych z repozytoriów. Służy do tego polecenie htpasswd. Tworzymy jednocześnie plik /home/subversion/.dav_svn.passwd oraz pierwszego użytkownika Subversion: htpasswd -cm /home/subversion/.dav_svn.passwd user1 Kolejnych użytkowników tworzymy już bez parametru (-c) zakładającego plik: htpasswd -m /home/subversion/.dav_svn.passwd user2 htpasswd -m /home/subversion/.dav_svn.passwd user3

85 KONFIGURACJA SERWERÓW
Czas teraz na stworzenie pliku /etc/apache2/auth-files/public-svn-authzfile, w którym przechowywane będą informacje na temat dostępu poszczególnych użytkowników SVN do repozytoriów. Przykładowa, bardzo prosta wersja uprawnień: # Konfiguracja grup [groups] owner = user1 faq-writers = user1 example-developers = user1, user2

86 KONFIGURACJA SERWERÓW
# Konfiguracja repozytoriów # Repozytorium nadrzędne. Tylko właściciel (user1) będzie # mógł dodawać nowe repozytoria [/] @owner = rw # Repozytorium FAQ - mogą go używać tylko członkowie grupy # faq-writers. Brak dostępu z zewnątrz [faq:/] @faq-writers = rw

87 KONFIGURACJA SERWERÓW
# Repozytorium example.org - mogą je modyfikować # tylko członkowie grupy example-developers. # Przeglądać mogą je wszyscy (opcja * = r) [example.org:/] @example-developers = rw * = r Oczywiście to tylko przykładowa definicja uprawnień. Każdy użytkownik musi być najpierw dodany programem htpasswd, aby móc korzystać z repozytorium SVN (nie licząc anonimowych użytkowników przeglądających repozytoria).

88 KONFIGURACJA SERWERÓW
Uprawnienia systemowe: Na koniec jeszcze jedna, bardzo istotna rzecz. Aby uwierzytelnianie przez Apache 2 zadziałało, właścicielem katalogu z repozytoriami Subversion powinien być właściciel procesu Apache 2. W Debianie jest to domyślnie użytkownik www-data. W innych dystrybucjach może to być inny użytkownik, np. apache czy apache2. W każdym bądź razie, jako ostatni punkt programu, ustalamy uprawnienia do katalogu /home/subversion: chown -R www-data:www-data /home/subversion/ W tym momencie, jeśli wszystkie czynności wykonaliśmy poprawnie, powinniśmy cieszyć się działającym i skonfigurowanym Subversion.

89 KONFIGURACJA SERWERÓW
Restart Apache 2: Nie zapomnijmy zrestartować naszego serwera Apache 2: /etc/init.d/apache2 restart

90 KONFIGURACJA SERWERÓW
Podstawy użycia: Możemy zacząć używać Subversion w praktyce. Na początku można dodać kilka plików do utworzonego wcześniej repozytorium faq. Wchodzimy więc do lokalizacji zawierającej folder, który chcemy zaimportować do repozytorium i wpisujemy: svn --username user1 import ~/faq \ -m „Komentarz” Ta operacja zaimportuje nam zawartość folderu ~/faq do repozytorium faq znajdującego się na serwerze z SVN, dodając odpowiedni komentarz (opcja -m).

91 KONFIGURACJA SERWERÓW
Aby sprawdzić, czy pliki zaimportowały się poprawnie do repozytorium, wystarczy wejść na stronę: i zalogować się. Zawartość repozytorium będziemy mogli zawsze przeglądać przez interfejs WWW. Jeśli chcemy, możemy również ściągnąć całe repozytorium na dysk innego komputera (np. w pracy). Wykonujemy w tym celu polecenie checkout (co): svn co

92 KONFIGURACJA SERWERÓW
W każdym miejscu, w którym mamy ściągnięte repozytorium faq, możemy teraz modyfikować dowolne pliki wchodzące w jego skład oraz zatwierdzać zmiany (przesyłane są one wtedy do głównego repozytorium). Aby pobrać aktualną wersję wszystkich plików z aktualnego katalogu wykonujemy komendę: svn update Natomiast, jeśli dokonaliśmy zmian w którymś z plików i chcemy je przesłać do repozytorium SVN (oczywiście operacja powiedzie się tylko w przypadku, gdy mamy dostęp do zapisu w danym repozytorium) użyjemy do tego komendy: svn commit plik Inną bardzo przydatną opcją w Subversion jest możliwość przeglądania zmian, jakie zaszły w danym pliku od ostatniej aktualizacji. Do przeglądania ostatnich zmian lokalnych możemy użyć komendy: svn diff

93 KONFIGURACJA SERWERÓW
Jeśli pracujemy w kilka osób na jednym pliku, łatwo jest nadpisać przypadkowo czyjeś zmiany. Na szczęscie dzięki inteligentnemu scalaniu oraz możliwości ręcznego decydowania o aplikacji poszczególnych zmian, utrata danych przestaje być praktycznie problemem (zmiany lokalne automatycznie scalane są ze zmiamami dokonanymi przez innych użytkowników podczas aktualizacji pliku komendą svn update). Jeśli jednak, mimo wszystko, chcemy czasowo zabronić innym użytkownikom zatwierdzania zmian z danym pliku, możemy użyć “zamka”: svn lock plik Zamek działa domyślnie do kolejnego zatwierdzenia zmian (svn commit). Jeśli jednak na pliku znajduje się atrybut –no-unlock (dodany np. podczas tworzenia bądź zatwierdzania zmian), zamek możemy zwolnić tylko przez wykonanie polecenia svn unlock plik.

94 SERWERY CVS Obecnie dostępne są dwa serwery cvs pierwszy to po prostu cvs skonfigurowany jako serwer działający wyłącznie na platformach Unix. Drugi to cvsnt, który powstał trochę później. CVSNT dostępny jest na platformy Windows Mac OS X, Solaris, HPUX i Linux. CVSNT obsługuje autentykacje przez Microsoft Active Directory lub SSH oraz szyfrowana autentykacje SSL, cvs serwer nie. Instalacja i konfiguracja cvsnt w odróżnieniu od cvs serwer jest łatwa ponieważ cvsnt jest aplikacją Windows i posiada własny program instalacyjny a konfiguracja polega na wpisywaniu odpowiednich wartości w okienka.

95 APLIKACJE KLIENCKIE Desktop-integrated clients.
Pierwsza grupa aplikacji klienckich cechuje się bardzo silnym poziomem integracji z systemami operacyjnymi dla których są przeznaczone. Integracja ta istnieje przede wszystkim na poziomie interfejsu, co z pewnością wpływa na ogromną łatwość i intuicyjność obsługi.

96 APLIKACJE KLIENCKIE TortoiseSVN Obsługa.
Istnieje wiele aplikacji, które w sposób przystępny (poprzez graficzny interfejs) udostępniają całą funkcjonalność systemu SVN. Najpopularniejszym z nich jest TortoiseSVN. Program ten dystrybuowany jest na licencji GNU General Public License, więc można go poprać za darmo ze strony projektu: Aplikacja oparta jest na jądrze platformy Windows i jest przeznaczona tylko dla niej. Pozwala zarządzać repozytoriami z poziomu popularnych okien systemu, więc jej obsługa jest dość prosta i intuicyjna. Obsługa. Program po zainstalowaniu udostępnia nam całą swoja funkcjonalność poprzez menu kontekstowe naszego systemu operacyjnego. Pierwszym krokiem jest stworzenie repozytorium. Aby to zrobić, należy kliknąć prawym przyciskiem myszy na folderze, w którym chcemy utworzyć repozytorium i z menu kontekstowego wybrać TortoiseSVN > Create repository here. W kolejnym kroku przechodzimy do lokalizacji, w której znajduje się nasz projekt. Klikamy na ikonę jego katalogu prawy klawiszem myszki i wybieramy SVN Checkout. Kolejne okno wymaga podania pewnych informacji: lokalizacji repozytorium (URL of repository) oraz lokalizacji katalogu z projektem (Checkout directory).

97 APLIKACJE KLIENCKIE Uwaga!
Jeżeli zamierzamy pracować z lokalnym repozytorium w polu URL of repository wpisujemy adres analogiczny do przedstawionego na rysunku.

98 APLIKACJE KLIENCKIE Stworzyliśmy już repozytorium dla naszego projektu, teraz poprzez dobrze znany nam Eksplorator Windows możemy nim zarządzać.

99 Strona domowa projektu
APLIKACJE KLIENCKIE Alternatywne aplikacje. Nazwa Platforma Strona domowa projektu KSvn Linux (Konqueror) SCPlugin Mac OS

100 APLIKACJE KLIENCKIE IDE plug-ins clients. Jest to grupa aplikacji, które nie mogą funkcjonować samodzielnie, są bowiem one rozszerzeniami funkcjonalnymi popularnych środowisk programistycznych, co czyni je bardzo praktycznymi z uwagi na fakt, że głównym zadaniem systemu SVN jest wspieranie i ułatwianie pracy programistów. Dzięki tej grupie produktów użytkownik nie jest skazany na korzystanie z 2 aplikacji i uciążliwe przełączanie się pomiędzy ich oknami.

101 APLIKACJE KLIENCKIE Subclipse
Instalacja. Aby zainstalować wtyczkę do środowiska Eclipse (wersja ) należ z menu Help wybrać Software Updates… a następnie w oknie, które się pojawiło wybrać zakładkę Available Software i kliknąć na Add site, kolejnym krokiem jest podanie lokalizacji plug-inu (w sieci lub lokalnej).

102 APLIKACJE KLIENCKIE Następnie z listy wybieramy interesujące nas elementy instalacji i klikamy na Install, kolejnych oknach potwierdzamy nasz wybór oraz warunki licencji i wybieramy Finish. Po ponownym uruchomieniu środowiska Subclipse jest gotowy do pracy.

103 APLIKACJE KLIENCKIE Obsługa. Przygotowanie środowiska.
Otwieramy perspektywę, w której będziemy mogli pracować z Subclipse, w tym celu z menu Window > Open Perspective > Other. Z listy wybieramy SVN Repository Exploring.

104 APLIKACJE KLIENCKIE Aby stworzyć repozytorium klikamy prawym przyciskiem myszy w otwartej w poprzednim kroku perspektywie i z menu wybieramy New > Repository Location. W kolejnym oknie jesteśmy pytani o lokalizację (jeśli chcemy pracować lokalnie wpisujemy adres według następującego wzoru: Warto również wspomnieć, że Subclipse daje nam wiele możliwości konfiguracyjnych w Window>Preferences>Team>SVN. Możemy między innymi wybrać ikony informujące o statusie identyczne do tych, które używane są w środowisku TortoiseSVN (pkt. 1.1.), co z pewnością ułatwi nam pracę.

105 APLIKACJE KLIENCKIE Operacje. Wszystkie najważniejsze operacje są teraz dostępne w menu kontekstowym wyświetlanym po kliknięciu prawym przyciskiem myszki w eksploratorze projektu, w menu Team. Mamy tu wszystkie potrzebne funkcje: możemy wysyłać i pobierać pliki z repozytorium, tworzyć nowe gałęzie projektu, przeglądać historię zmian…

106 APLIKACJE KLIENCKIE Szczególnie ciekawą i użyteczną jest opcja View file history as graph, która graficznie, w sposób czytelny i jasny przedstawia historię i hierarchię projektu z punktu widzenia repozytorium. Dzięki Synchronize with Repository możemy śledzić wszystkie zmiany jakie zaszły w naszym projekcie od poprzedniej wersji, po kliknięciu na Open in Compare Editor mamy możliwość porównania i edycji zmian w poszczególnych plikach.

107 APLIKACJE KLIENCKIE Alternatywne aplikacje. Nazwa Środowisko
Strona domowa projektu Subversive Eclipse VisualSVN Visual Studio AnkhSVN

108 USŁUGI HOSTINGOWE Nie każdy ma okazję postawienia własnego serwera SVN lub CVS. W takim przypadku warto zainteresować się darmowymi rozwiązaniami, które do zadań niekomercyjnych często w zupełności wystarczają. Oto kilka z nich: Assembla BountySource CVSDude Google Code Launchpad SourceForge.net Unfunddle OpenSVN

109 USŁUGI HOSTINGOWE Assembla
- ogromne możliwości związane z zarządzaniem projektem i pracą grupową, - 200 MiB na repozytorium (SVN, Git oraz Mercurial) - brak informacji o zasadach użytkowania - w wersji darmowej można korzystać z ograniczeń dostępu ciężko więc określić czy dotyczy tylko projektów Open Sourse - wielu użytkowników wskazuje na to, iż licencja projektów nie jest w żaden sposób wymuszana - od niedawana jednak nie można już trzymać zamkniętych projektów (komercyjnych za darmo) - w ciągu roku SVN nie było dostępne tylko raz – upgrade serwisu - dostęp do http a nie https - interfejs przez WWW jest czasami strasznie wolny -zgrywanie plików (przez upload na stronie, nie przez SVN) większych niż 1MB kończy się dość często niepowodzeniem po godzinie czekania

110 USŁUGI HOSTINGOWE 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 czy też objętości kodu - jasne warunki użytkowania

111 USŁUGI HOSTINGOWE CVSDude - udostępnia serwer CVS oraz SVN
- ograniczone repozytorium do 2MiB - dostęp tylko przez jednego użytkownika - w momencie tworzenia aplikacji Open Source warunki są możliwe do negocjacji, trzeba wtedy wysłać maila do obsługi - warunki usług nie różnią się zbytnio od innych prezentowanych rozwiązań

112 USŁUGI HOSTINGOWE Google Code
- dla niekomercyjnych projektów Open Source - dostęp do SVN z limitem repozytorium do 100MiB - miejsce dla plików – kolejne 100MiB - Wiki oraz proste zarządzanie znalezionymi błędami - stosunkowo wolny

113 USŁUGI HOSTINGOWE Launchpad
- hosting Canionicala dla projektów Open Source - systemem kontroli wersji jest Bazaar - tracker kodu i błędów - własne repozytorium dla Ubuntu - system wspomagania tłumaczenia projektu - brak informacji o ograniczeniach pojemnościowych usługi - dużo ograniczeń związanych z licencja

114 USŁUGI HOSTINGOWE OpenSVN
- brak ograniczeń co do limitu pasma oraz rozmiaru repozytorium (zwiększenie limitu przepustowości oraz rozmiaru repozytorium można uzyskać na osobistą prośbę) - brak ograniczeń zawartości dla repozytorium (zabronione jest umieszczanie materiałów nielegalnych i pornograficznych) - OpenSVN nie jest Open Source - zdarzają się utraty projektów po przejściu w stan offline na dłuższy okres

115 USŁUGI HOSTINGOWE SourceForge.net
- jedna z najstarszych usług związanych z Otwartym Oprogramowaniem - udostępnia serwer CVS, SVN, Wiki, trackera - możliwość udostępniania plików - serwer WWW wraz z baza 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 - brak informacji odnośnie ograniczeń pojemnościowych - projekt trzeba najpierw zgłosić i opisać (odmowa w przypadku stwierdzenia, że projekt może zbytnio obciążyć serwis) - zastrzegają prawa do tego, aby w przyszłości móc wykorzystać postawiony u nich kod do rozbudowy serwisu

116 USŁUGI HOSTINGOWE Unfunddle - hosting wspiera Git oraz SVN
- w wersji bezpłatnej wiele ograniczeń - na repozytoria 200MiB - ograniczenie do dwóch osób mogących brać udział w projekcie - brak obostrzeń dotyczących licencji projektu

117 PROJEKT WYKONALI Jabłonowski Mateusz Jagiełło Maciej Niedzielan Paweł
Pawula Krzysztof Stelmaszyk Błażej Zieliński Piotr Grupa 432IDM IO