Czym jest Subversion?

Subversion jest darmowy o otwartym źródle systemem kontroli wersji. Oznacza to, że Subversion zarządza plikami, katalogami i zmianami wprowadzanymi w miarę upływu czasu. To pozwala na odzyskanie starszej wersji twoich danych lub przeglądnięcie historii zmian na plikach. W związku z tym, wielu ludzi myśli o systemach kontroli wersji jak o swego rodzaju „wehikule czasu.

Subversion może działać przez sieć, która umożliwia wykorzystanie go przez różne platformy. Na pewnym poziomie pozwala rożnym osobą współpracować, modyfikować i zarządzać tym samym zestawem danych. Ponieważ zmiany są wersjonowane, masz pewność, że źle wprowadzone dane mogą zawsze być cofnięte do prawidłowej wersji.

Niektóre systemy kontroli wersji są równocześnie oprogramowaniem zarządzania kodem źródłowym (SCM). Systemy te są szczególnie dostosowane do zarządzania drzewem kodu źródłowego i mają wiele cech które są specyficzne dla oprogramowania, lub dostarczają narzędzia do budowania oprogramowania. Subversion nie należy do tego typu systemów, może być wykorzystany do dowolnego zbioru plików. Dla ciebie jest obojętne czy to są pliki z kodem źródłowym, tekstowe - lista zakupów, czy cyfrowe wideo i inne różne cyfrowe dokumenty.

Czy Subversion jest odpowiednim narzędziem?

Jeśli jesteś użytkownikiem lub administratorem i zastanawiasz się nad użyciem Subversion, pierwszym pytaniem będzie: "Czy to jest właściwe narzędzie do pracy?" Subversion jest potężnym systemem i nie zawsze musi być użyty do prostych czynności.

Jeśli potrzebujesz narzędzia do archiwizowania starych wersji plików, ewentualnie je przywracać, historii zmian i możliwości pracy grupowej, to Subversion jest właśnie dla ciebie. Jeśli chcesz współpracować z innymi ludźmi nad rozwojem dokumentów (zwykle za pośrednictwem sieci), śledzić i monitorować zmiany, to Subversion też powinno być wykorzystane. Subversion idealnie nadaje się dla grup programistów, którzy działają wspólnie rozwijając tą samą kopie danych. Subversion ułatwia pracę programistą. Oczywiście to wszystko kosztuje, dodatkowa praca administratora, narzut pamięci dyskowej, dodatkowe dane do archiwizowania i wykonywania kopii bezpieczeństwa. Praca z Subversion wymaga znajomości poleceń i ich opcji by sprawnie zarządzać repozytorium.

Zakładając, że nie przerażają cie dodatkowe prace ani informacje do przyswojenia, upewnij się czy za pomocą Subversion rozwiążesz swój problem. Nie używaj Subversion do dystrybuowania zbiorów zdjęć, muzyki, oprogramowania lub pakietów. Problemem jest to, że tego rodzaju dane zwykle nie zmieniają się w ogóle. Zbiór rozrasta się w miarę upływu czasu, ale poszczególne pliki w kolekcji nie są zmieniane. W tym przypadku Subversion kompletnie się nie sprawdza. [2] Istnieją narzędzia, które lepiej spełniają oczekiwania powyższego przypadku. Bez narzutu wersjonowania zmian. To są np.: rsync lub unison.

Historia Subversion

W roku 2000, CollabNet, Inc. (http://www.collab.net) rozpoczął poszukiwanie deweloperów do napisania zamiennika CVS. CollabNet oferował pakiet oprogramowania CollabNet Enterprise Edition (CEE), z którego jeden element to kontrola wersji. Chociaż CEE wykorzystywało CVS w jego pierwotnej wersji, CVS miał ograniczenia od samego początku, a CollabNet postanowił zmienić CVS na coś lepszego. Niestety, CVS stał się de facto standardem w świecie open source głównie ze względów braku innego podobnego oprogramowania (na wolnej licencji). CollabNet postanowił stworzyć nowe oprogramowanie od podstaw do kontroli wersji, zachowując idee CVS, ale z pominięciem błędów.

W lutym 2000, skontatkowano się z Karl Fogel, autorem Open Source Development with CVS (Coriolis, 1999) i zapytano czy nie zechciałby pracować przy tym nowym projekcie. Przypadkowo, w tym samym czasie Karl omawiał powstanie nowego systemu kontroli wersji ze swoim znajomym Jim Blandy. W 1995 rozpoczęli działalność pod szyldem Cyclic Software, firma, która zapewniała wsparcie w CVS. Obaj sprzedali firmę, ale nadal wykorzystywali CVS w pracy. Ich frustracja z CVS doprowadziła, że Jim zaczął poważnie myśleć nad lepszym sposobem kontroli wersji, wymyślił nową nazwę „Subversion”, ale także koncepcje systemy zarządzania wersjami. Karl bez zastanowienia rozpoczął współpracę nad projektem w CollabNet, a Jim został wydelegowany przez swojego pracodawcę Red Hat Software do pracy nad projektem na czas nieokreślony. CollabNet zatrudnił Karl i Ben Collins-Sussman i prace rozpoczeły się w maju 2000 r. Z pomocą doświadczonych pracowników CollabNet – Briand Behlendorf i Jason Robbins, Subversion rozpoczęło szybki wzrost popularności wśród programistów ze względu na frustrujące utrudnienia w istniejącym systemie kontroli wersji (CVS).

W pierwotnym etapie projektowania postawiono kilka ważnych i prostych celów. Nie chcą odkrywać na nowo technik wersjonowania danych, oni po prostu chcą naprawić CVS. Zdecydowali że Subversion będzie się pokrywać z CVS jeśli chodzi o funkcjonalność, ale nie skopiują podstawowych błędów z CVS. Chodziło o to by dotychczasowi użytkownicy CVS mogli w prosty sposób „przeskoczyć” na Subversion.

Po 14 miesiącach kodowania, stał się samo wystarczalny 31 sierpnia, 2001 roku. Oznacza to, że programiści Subversion przestali używać CVS do wersjonowania zmian w projekcie, a użyto do tego właśnie samego Subversion.

CollabNet rozpoczął projekt i opłacał nadal kilku programistów w pełnym wymiarze godzin. Mimo że projekt był rozwijany jak każdy inny open source. Subversion udostępnia Subversion na licencji praw autorskich zgodnej z wytycznymi Debiania dotyczącymi wolnego oprogramowania. W innym znaczeniu, każdy ma prawo pobrać, zmodyfikować i rozpowszechniać Subversion jak on chce, bez wymaganej zgody CollabNet.

Architektura Subversion

Rysunek 1, „Architektura Subversion” przedstawia koncepcje projektu Subversion.

Rysunek 1. Architektura Subversion

Architektura Subversion

Na jednym końcu jest repozytorium Subversion, które przechowuje twoje wersje danych. Na drugim końcu jest twój klient Subversion, który zarządza częścią tych danych lokalnie zwane „working copies”. Pomiędzy tymi warstwami jest wiele ścieżek poprzez różne metody dostępu do repozytorium. Można wykorzystywać sieć lub dostęp bezpośredni.

Składniki Subversion

Subversion, po zainstalowaniu posiada wiele różnych składników. Oto krótki przegląd tego, co otrzymujesz. Nie przejmuj się w tym miejscu skąpym opisem tych składników, ponieważ wiele stron tej książki traktuje szerzej na ich temat.

svn

Polecenie wiersza poleceń - klient Subversion

svnversion

Program przedstawia stan w jakim znajdują się pliki w repozytorium

svnlook

Narzędzie do inspekcji repozytorium

svnadmin

Narzędzie do tworzenia, optymalizowania lub naprawy repozytorium Subversion

mod_dav_svn

Moduł serwera Apache, wykorzystywany do udostępniania repozytorium Subversion za pomocą protokołu WebDAV

svnserve

Dedykowany serwer svn, może działać z pomocą serwera SSH (secure shell). To pozwala na dostęp do repozytorium na różne sposoby.

svndumpfilter

Program do filtrowania wygenerowanego zrzutu z repozytorium (dump)

svnsync

Program do mirrorowania repozytorium do innego za pośrednictwem sieci.

Co nowego w Subversion

Pierwsze wydanie tej książki wyszło w 2004 roku, wkrótce po tym jak opublikowano wersje 1.0 oprogramowania Subversion. Kolejne cztery lata przyniosły pięć głównych wersji aplikacji usprawniających, naprawiających błędy i rozwijających nowe funkcjonalności. Staraliśmy się utrzymać wersję on-line na bieżąco ze zmianami w oprogramowaniu. Drugie wydanie O'Reilly obejmuje dokumentacje dotyczącą wersji 1.5. Oto krótkie podsumowanie najistotniejszych zmian od Subversion 1.0. Należy pamiętać, że ta lista nie jest kompletna, szczegóły zostały umieszczone na oficjalnej stronie Subversion http://subversion.tigris.org.

Subversion 1.1 (Wrzesień 2004)

Opublikowanie wersji 1.1 zapoczątkowało mechanizm FSFS, „flat-file” - opcja przechowywania danych repozytorium. Chociaż Berkley DB jest nadal używane i obsługiwane, to FSFS stało się domyślną metodą przechowywana dla nowo utworzonych repozytoriów ze względu na jej łatwość obsługi. Również w tym wydaniu dodano wsparcie do wersjonowania dowiązań symbolicznych, lokalizacji interfejsu.

Subversion 1.2 (Maj 2005)

Kolejna wersja przyniosła możliwość tworzenia blokad plików po stronie serwera (na czas edycji). Dodatkowo udostępniono implementacje WebDAV dzięki czemu stało się możliwe „podłączania” zdalnego dysku, który faktycznie był repozytorium SVN. Rozpoczęto również prace nad optymalnym algorytmem do kompresji repozytorium i szybkiego pobierania starszych wersji danych.

Subversion 1.3 (Grudzień 2005)

W wersji 1.3 wprowadzone zostały możliwości autoryzacji na podstawie ścieżek (oczywiście moduł do serwera Apache już umożliwiał to wcześniej, a nowa funkcjonalność dotyczyła dedykowanego rozwiązania Subversion: svnserver). Do modułu Apache dodano kilka nowych funkcjonalności, jak nowe możliwości logowania.

Subversion 1.4 (Wrzesień 2006)

Wersja 1.4 wprowadza całkowicie nowe narzędzie svnsync odpowiadające za wykonywania kopii lustrzanej (wyłącznie do odczytu) repozytorium. Metadane zostały przeorganizowane – przestano dłużej korzystać z XML co skutkowało w oszczędnościach w czasie po stronie klienta SVN. Natomiast Berkley DB zyskał zdolność do automatycznego odzyskiwania się po awarii serwera.

Subversion 1.5 (Czerwiec 2008)

Wersja 1.5 zabrała o wiele więcej czasu niż jej poprzednicy. Za tak długi czas oczekiwania na nową wersje, wynagrodzono sporym przyrostem w zmianach. Półautomatyczne śledzenie rozgałęzień i ich łączenie. To był duży ukłon dla użytkowników Subversion, niemożliwe do osiągnięcia przez CVS. Zbliżyło to SVN do grupy aplikacji takich jak Perforce czy ClearCase. Oczywiście ta wersja wprowadziło sporo innych usprawnień czy całkowicie nowych funkcjonalności. Tak jak interaktywne rozwiązywanie konfliktów, częściowe „checkout”, wsparcie dla autoryzacji za pomocą SASL w svnserve.

Subversion 1.6 (???)

???



[2] Or as a friend puts it, „swatting a fly with a Buick.