Przeczytałeś już o kopiach roboczych, teraz pokażemy, w jaki sposób klient Subversion tworzy je i wykorzystuje.

Kopia robocza Subversion jest zwykłym drzewem katalogów w systemie lokalnym, zawierającym zbiór plików. Możecie edytować te pliki do woli, a jeśli są to pliki z kodem źródłowym, można z nich skompilować program w zwykły sposób. Kopia robocza jest prywatnym miejscem pracy: Subversion nie wprowadza zmian innych ludzi, ani czyni własnych zmian dostępnych innym, dopóki wyraźnie nie dacie znać, by to uczynić.

Po dokonaniu pewnych zmian na plikach w kopii roboczej i sprawdzeniu, czy działają poprawnie, Subversion dostarcza ci poleceń publikacji zmian dla innych osób pracujących razem nad projektem (zapisując do repozytorium). Jeśli inni ludzie publikują własne zmiany, Subversion daje wam polecenia do scalenia tych zmian w katalogu roboczym (poprzez odczyt z repozytorium).

Kopia robocza zawiera również pewne dodatkowe pliki, tworzone i zarządzane przez Subversion, wspomagające realizację tych poleceń. W szczególności wasza kopia robocza zawiera podfolder o nazwie .svn, znany również jako folder administracyjny kopii roboczej. Pliki w tym folderze administracyjnym pomagają Subversion rozpoznać, które pliki zawierają nieopublikowane zmiany, a które są nieaktualne względem pracy innych osób. Przed wersją 1.7, Subversion utrzymywał foldery administracyjne .svn w każdym wersjonowanym folderze kopii roboczej. Subversion 1.7 przyjął zupełnie inne podejście i każda kopia robocza posiada teraz tylko jeden folder administracyjny znajdujący się w głównym folderze kopii roboczej.

Typowe repozytorium Subversion często zawiera pliki (lub kod źródłowy) kilku projektów, zazwyczaj każdy projekt jest podfolderem drzewa katalogów w systemie plików. W tym układzie kopia robocza użytkownika zazwyczaj odpowiada szczególnemu poddrzewu repozytorium.

Załóżmy dla przykładu, że macie repozytorium, zawierające dwa projekty programów.

Rysunek 2.6. Struktura plików repozytorium

Innymi słowy, korzeń drzewa katalogów repozytorium ma dwa podkatalogi: paint i calc.

Aby otrzymać kopię roboczą, musicie pobrać pewne poddrzewo z repozytorium. (Termin pobrać może brzmieć jakby miał coś wspólnego z blokadą lub rezerwacją zasobów, ale tak nie jest, polecenie po prostu tworzy prywatną kopię projektu dla Was.)

Załóżmy, że wprowadziliście zmiany do przycisk.c. Ponieważ katalog .svn pamięta datę modyfikacji pliku i oryginalną zawartość, Subversion może powiedzieć, że zmieniliście plik. Jednak Subversion nie uczyni zmian publicznymi aż wyraźnie to powiecie. Akt publikowania zmian jest bardziej znany jako zatwierdzenie (lub zarezerwowanie ) zmiany do repozytorium.

Aby ujawnić zmiany innym, możesz użyć polecenia Subversion commit (zatwierdź).

Teraz zmiany pliku przycisk.c zostały zatwierdzone i przesłane do repozytorium, jeśli inny użytkownik pobiera kopię roboczą /calc, będzie widzieć zmiany z najnowszej wersji pliku.

Załóżmy, że macie współpracownika, Agatkę, która pobiera kopię roboczą /calc w tym samym czasie co wy. Kiedy zatwierdzacie swoje zmiany na przycisk.c, kopia robocza Agatki pozostaje bez zmian; Subversion modyfikuje kopie robocze tylko na życzenie użytkownika.

Aby doprowadzić swój projekt najnowszego stanu, Agatka może poprosić Subversion o uaktualnienie jej kopii roboczej, za pomocą polecenia Subversion update (uaktualnij). Pozwoli to uwzględnić wprowadzone przez Was zmiany do jej kopii roboczej, jak również wszelkie inne, które zostały zatwierdzone od czasu tego uaktualnienia.

Należy pamiętać, że Agatka nie musi określać, które pliki uaktualnić; Subversion używa informacji zawartych w katalogu .svn, i kolejnych informacji z repozytorium, aby zdecydować, które pliki muszą być uaktualnione.

Dostęp do repozytoriów Subversion można uzyskać za pomocą różnych metod - z dysku lokalnego lub za pośrednictwem różnych protokołów sieciowych. Lokalizacja repozytorium jednak zawsze jest adresem URL. Schemat URL wskazuje metodę dostępu:

W większości adresy URL dla Subversion używają standardowej składni, dopuszczającej, by nazw serwerów i numerów portów były określone jako część adresu URL. Metoda dostępu file:// jest zazwyczaj używana do dostępu lokalnego, chociaż może być używana ze ścieżką UNC do hosta w sieci. Dlatego URL przybiera formę file://nazwaHosta/sciezka/do/repozytorium. Na komputerze lokalnym, częśćnazwaHosta adresu URL musi być pusta lub localhost. Z tego powodu, w lokalnych ścieżkach zwykle pojawiają się trzy ukośniki, file:///ścieżka/do/repozytorium.

Ponadto użytkownicy schematufile:// na platformie Windows będą musieli korzystać z nieoficjalnie „standardowej” składni dostępu do repozytoriów, które są na tej samej maszynie, ale na innym dysku niż bieżący dysk roboczy klienta. Obie z poniższych składni ścieżki URL działają, przy czym X jest dyskiem, na którym znajduje się repozytorium:

file:///X:/sciezka/do/repoz
...
file:///X|/sciezka/do/repoz
...
      

Należy pamiętać, że adres URL używa zwykłych ukośników pomimo że natywna (nie URL) forma ścieżki w Windows używa odwrotnych ukośników.

Możecie uzyskać dostęp do repozytorium FSFS przez udziały sieciowe, ale to nie jest zalecane z różnych powodów:

Operacja svn commit pozwala opublikować zmiany dla dowolnej liczbie plików i katalogów jako pojedyncza transakcja atomowa. W swojej kopii roboczej możecie zmienić zawartość plików, tworzyć, usuwać, zmieniać nazwy i kopiować pliki i katalogi, a następnie zatwierdzić komplet zmian w pojedynczym działaniu.

W repozytorium każde zatwierdzenie jest traktowane jako transakcja atomowa: albo nastąpiło zatwierdzenie wszystkich zmian, albo żadna z nich nie dochodzi do skutku. Subversion zachowuje tą niepodzielność wobec awarii programów, awarii systemu, problemów z siecią i działań innych użytkowników.

Za każdym razem, gdy repozytorium akceptuje zatwierdzenie, tworzy nowy stan drzewa systemu plików, zwanego wersją. Każda wersja ma przypisaną unikalną liczbę naturalną, o jeden większą niż liczba wcześniejszej wersji. Początkowa wersja świeżo utworzonego repozytorium ma numer zero i składa się wyłącznie z pustego katalogu.

Dobrym sposobem, wizualizacji repozytorium jest szereg drzew. Wyobraźcie sobie szereg numerów wersji, zaczynając od 0, ciągnący się z lewej do prawej. Każdy numer wersji ma poniżej dołączone drzewo plików, a każde drzewo jest „migawką” wyglądu repozytorium po każdym zatwierdzeniu.

Rysunek 2.7. Repozytorium

Ważne jest, aby pamiętać, że kopie robocze nie zawsze odpowiadają pojedynczym wersjom w repozytorium, mogą zawierać pliki z kilku różnych wersji. Na przykład załóżmy, że pobierzecie kopię roboczą z repozytorium, którego najnowszą wersją jest 4:

calc/Makefile:4
integer.c:4
button.c:4
      

W chwili obecnej ten katalog roboczy odpowiada dokładnie wersji 4 w repozytorium. Załóżmy jednak, że dokonujecie zmiany w przycisk.c i zatwierdzacie tą zmianę. Zakładając, że żadne inne zatwierdzenia nie miały miejsca, wasze zatwierdzenie stworzy wersję 5 repozytorium, a wasza kopia robocza będzie teraz wyglądać tak:

calc/Makefile:4
integer.c:4
button.c:5
      

Załóżmy, że w tym momencie Agatka wprowadza zmianę w naturalna.c, tworząc wersję 6. Jeśli użyjecie svn update, aby zaktualizować swoją kopię roboczą, to będzie ona wyglądać tak:

calc/Makefile:6
integer.c:6
button.c:6
      

Zmiany Agatki w naturalna.c pojawią się w twojej kopii roboczej, a wasze zmiany będą nadal obecne w przycisk.c. W tym przykładzie treść Makefile jest identyczna w wersjach 4, 5 i 6, ale Subversion zaznacza waszą kopię roboczą Makefile wersją 6 by wskazać, że jest nadal aktualna. Tak więc, po wykonaniu czystej aktualizacji na korzeniu kopii roboczej, na ogół będzie ona odpowiadała dokładnie jednej wersji w repozytorium.

Dla każdego pliku w katalogu roboczym Subversion przechowuje dwie zasadnicze części informacji w przestrzeni administracyjnej .svn/:

Uwzględniając te informacje, podczas komunikacji z repozytorium, Subversion może stwierdzić, w jakim z następujących czterech stanów znajduje się plik roboczy: