Manuals

Subversion w akcji

Kopie robocze

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

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.

Adresy URL repozytorium

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:

Tabela 2.1. URL dostępu do repozytorium

SchematMetoda dostępu
file:// Bezpośredni dostęp do repozytorium na dysku lokalnym lub sieciowym.
http:// Dostęp przez protokół WebDAV do serwera Apache z zainstalowanym Subversion.
https:// To samo co http://, ale z szyfrowaniem SSL.
svn:// Nieuwierzytelniony dostęp TCP/IP za pośrednictwem niestandardowego protokołu do serwera svnserve.
svn+ssh:// uwierzytelniony, szyfrowany dostęp TCP/IP za pośrednictwem niestandardowego protokołu do serwera svnserve.

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:

  • Dajecie bezpośredni dostęp do zapisu wszystkim użytkownikom, zatem mogą oni przypadkowo usunąć lub uszkodzić system plików repozytorium.

  • Nie wszystkie protokoły udostępniania plików w sieci wspierają blokady wymagane przez Subversion. Pewnego dnia możecie zastać wasze repozytoria z lekka uszkodzone.

  • Musicie ustawić uprawnienia dostępu w odpowiedni sposób. SAMBA jest pod tym względem szczególnie trudna.

  • Gdy jakaś osoba zainstaluje nowszą wersję klienta, która zaktualizuje format repozytorium, wszyscy inni nie będą mogli uzyskać dostępu do repozytorium, póki nie zaktualizują klienta do nowej wersji.

Wersje

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

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.

Jak kopie robocze monitorują repozytorium

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

  • na jakiej wersji bazuje plik roboczy (jest to tzw wersja robocza pliku) oraz

  • znacznik czasu zapisu kiedy lokalna kopia została zaktualizowana w repozytorium.

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:

Bez zmian i aktualny

Plik jest niezmieniony w katalogu roboczym i żadne zmiany w tym pliku nie zostały zapisane w repozytorium od jego wersji roboczej. Polecenie commit na tym pliku nic nie zmieni ani update na pliku nic nie zdziała.

Lokalnie zmieniony i aktualny

Plik został zmieniony w folderze roboczym i żadne zmiany w tym pliku nie zostały zapisane w repozytorium od jego wersji roboczej. Istnieją lokalne zmiany, które nie zostały zatwierdzone do repozytorium, a tym samym polecenie commit na pliku powiedzie się opublikowaniem zmian a update pliku nic nie zdziała.

Bez zmian i nieaktualny

Plik nie został zmieniony w folderze roboczym, ale został zmieniony w repozytorium. Plik powinien ostatecznie zostać zaktualizowany, aby był zgodny z wersją publiczną. Polecenie commit na pliku nie zrobi nic, a update pliku wprowadzi najnowsze zmiany do kopii roboczej.

Lokalnie zmieniony i nieaktualny

Plik został zmieniony zarówno w folderze roboczym, jak i w repozytorium. Polecenie commit na pliku zakończy się niepowodzeniem z błędem nieaktualny. Plik powinien najpierw zostać zaktualizowany; polecenie update będzie próbowało scalić zmiany publiczne zmiany z lokalnymi. Jeśli Subversion nie uda się zakończyć automatycznego scalenia w sposób nadający się do przyjęcia, pozostawia rozwiązanie konfliktu przez połączenie zmian użytkownikowi.

TortoiseSVN homepage