Komputery, oprogramowanie, internet i okolice
Kategorie: Wszystkie | Aplikacje | Blog | Dev | Hacks | Linux | Subversion | Varia | gry | khoomei | książki | mjuzik
RSS

Subversion

czwartek, 15 kwietnia 2010

Przygotowując poprzedni wpis o kolorowaniu konsolowych narzędzi jakoś umknął mi jeszcze jeden bardzo pożyteczny srypt, który ułatwi pracę z Subversion.

ColorSVN

colorsvn

Narzędzie colorsvn koloruje informacje o zmianach w plikach (svn status, svn add, svn checkoout, etc), dzięki niemu od razu widać które pliki zostały dodane, które zmienione, a które usunięte.

Niestety w przeciwieństwie do wspomnianego poprzednio colordiff w repozytorium Ubuntu nie znajdziemy gotowej paczki dla ColorSVN. Na szczęście instalacja jest banalnie prosta.

  1. Ściągamy źródła z działu Downloads projektu:
    $ wget http://www.console-colors.de/downloads/colorsvn/colorsvn-0.3.2.tar.gz
  2. Rozpakowujemy paczkę:
    $ tar xvfz colorsvn-0.3.2.tar.gz
  3. Przechodzimy do katalogu ze źródłem i instalujemy:
    $ cd colorsvn-0.3.2/
    $ .configure
    $ make
    $ sudo make install
  4. Jeśli, jak radziłem w poprzednim wpisie mamy ustawioną zmienną $TERM o wartości xterm-256color musimy jeszcze dopisać ten typ terminala do pliku konfiguracyjnego (gdzie przy okazji możemy zmienić też definicje kolorów). W linii 15 pliku /etc/colorsvnrcdopisujemy xterm-256color
  5. Teraz już tylko pozostało dopisać do ~/.bashrc odpowiedni alias:
    alias svn='colorsvn'

Jeśli wszystko wykonaliśmy poprawnie możemy już się cieszyć jeszcze wygodniejszą pracą z Subversion.

Na marginesie dodam, że na stronie projektu znaleźć można jeszcze między innymi ColorCVS, ColorMake i ColorGCC

sobota, 31 października 2009

1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word

Dla wszystkich z niecierpliwością oczekających na kolejną część niedokończonego cyklu o Subversion mam dobrą wiadomość! Po nieprzyzwoicie długiej przerwie oto przed wami kolejny odcinek poradnika.

Muszę przyznać, że po przesiadce na Linuksa większość czynności związanych z obsługą Subversion wykonuję z poziomu konsoli. Tak jest o wiele szybciej i wygodniej (praca w bashu to przyjemność, czego nie można powiedzieć o windowsowym cmd). Czasem jednak zdarzają się momenty gdy łatwiej jest coś wyklikać. Na Windowsie można było skorzystać ze świetnego TortoiseSVN. A jak sprawa wygląda na systemach linuksowych? Bardzo dobrze wygląda!

RabbitVCS

RabbitVCS (wcześniej znany jako NautilusSVN) w obecnej fazie rozwoju pozwala na integrację z menadżerem plików Nautilus (domyślnym w środowisku GNOME) oraz obsługę repozytoriów Subversion. Autorzy nie zamierzają na tym poprzestać i w najbliższej przyszłości można się spodziewać dodania obsługi innych systemów kontroli wersji, jak i integracji z innymi menadżerami plików.

Integracja z Nautilusem

RabbitVCS dostępny jest z menu Plik lub z menu kontekstowego wersjonowanych plików i folderów.

W przypadku folderu nie objętego kontrolą wersji zobaczymy:

Mamy więc łatwy dostęp do wszystkich potrzebnych narzędzi. Jeśli ktoś pracował z TortoiseSVN na pewno poczuje się jak w domu. Mam wrażenie, że RabbitVCS jest nawet trochę inteligentniejszy od swojego windowsowego odpowiednika i poszczególne elementy menu pokazują się tylko wtedy gdy rzeczywiście są potrzebne (np możliwość łatwego dodania do ignorowanych lub dodania do repozytorium niewersjonowanego pliku).

Możliwości

Jest praktycznie wszystko czego potrzeba w codziennej pracy:

  • ikony dla plików i folderów
  • przeglądarka logów


  • okno wysyłania commitu


  • branchowanie/tagowanie


  • tworzenie plików diff i ich użycie
  • przeglądarka blame/annotate


  • przeglądarka zmian w kodzie z użyciem świetnego Meld (można też ustawić inne narządzie do przeglądania zmian)


  • ułatwienia przy mergowaniu zmian
  • dostęp do wszystkich okien dialogowych z konsoli

Czego brakuje?

W porównaniu z TortoiseSVN brakuje prostej przeglądarki repozytorium (ma się pojawić w wersji 0.13), generowania grafów z historią zmian, czy też generowania statystyk (ale czy rzeczywiście jest to aż tak potrzebne? Nie sądze).

piątek, 01 sierpnia 2008
1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word


W notce Subversion - instalacja i tworzenie repozytorium opisałem jak skonfigurować serwer Subversion jako usługę systemu Windows i jak zakładać repozytoria. Głównym minusem tego rozwiązania jest potrzeba wykonywania wszystkich poleceń z poziomu konsoli.


Kilka dni temu natknąłem się na bardzo ciekawe rozwiązanie. VisualSVN Server, bo o nim tu mowa, to darmowy pakiet zawierający Subversion, Apache'a i graficzny panel administracyjny.
Instalacja jest niesamowicie prosta. W zasadzie wystarczy klikać cały czas "Next"



Jeśli chcemy możemy wybrać katalog instalacyjny i katalog zawierający repozytoria oraz zdecydować się czy połączenia mają być szyfrowane.
Mamy również do dyspozycji panel administracyjny:



W prosty sposób możemy uruchamiać i zatrzymywać serwer, zarządzać użytkownikami i ich prawami, tworzyć i kasować repozytoria czy przeglądać ich zawartość.
Po kliknięciu prawym przyciskiem na repozytorium możemy ustawić specyficzne dla niego opcje:



Ustawiamy tu uprawnienia dla użytkowników oraz możemy przypisać skrypty wywoływane w wyniku zdarzeń w repozytorium.

Jeśli ktoś nie chce by serwer uruchamiał się z systemem musi przejść do Panelu sterowania, wybrać Narzędzia administracyjne a następnie Usługi. Teraz wystarczy we właściwościach usługi VisualSVN Server zmienić typ uruchomienia na Ręczny.

Jako, że dostęp do repozytorium odbywa się za pomocą protokołu HTTP możemy przeglądać jego zawartość z użyciem WebDAV!



Domyślny wygląd możemy zmienić edytując pliki svnindex.css i svnindex.xsl znajdujące się w katalogu htdocs VisualSVN Server.
piątek, 25 kwietnia 2008
1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word


Po dość długiej przerwie znalazłem w końcu czas na kontynuację poradnika Subversion.

W poprzednich częściach przedstawiłem jak zainstalować Subversion, jak utworzyć repozytorium i jak z niego korzystać. W zasadzie wiele więcej nie jest potrzebne by efektywnie pracować z wersjonowanymi plikami. Pojawia się tylko jedno małe "ale" - do tej pory wszystkie komendy wprowadzaliśmy z poziomu konsoli. Dla wielu osób może być to spora bariera, czasem nie do przeskoczenia. Na szczęście jest rozwiązanie prawie idealne - klient graficzny integrujący się z powłoką systemu.

TortoiseSVN



Pakiet instalacyjny wraz z polskim tłumaczeniem można pobrać ze strony projektu. Tu ujawnia się jedna z nielicznych wad tego narzędzia - jest dostępny tylko dla systemu Windows.

Integracja z powłoką systemu



Polecenia TortoiseSVN dostępne są z poziomu menu kontekstowego jak i menu Plik w Eksploratorze Windows. Dodatkowo ikony wersjonowanych plików uzupełnione są o małe ikonki informujące o stanie pliku



Przeglądarka repozytorium



Możemy w prosty sposób przeglądać pliki znajdujące się w repozytorium.

Sprawdzanie zmian



Możemy sprawdzać jakie zmiany zostały wprowadzone w kopii roboczej i w repozytorium.

Czytanie loga



Mamy łatwy dostęp do wpisów w logu z opisem zmian w plikach.

Blame



Sprawdzanie kto, kiedy i jakie zmiany wprowadził.

Porównywanie zmian



Wbudowana przeglądarka zmian pomiędzy wersjami.

Graf rozwoju projektu



Statystyki




Dodatkowo TortoiseSVN można wykorzystać w aplikacjach trzecich. W jednym z najbliższych wpisów zaprezentuję przykład takiego zastosowania.
czwartek, 13 grudnia 2007
1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word


Skoro już wiemy jak Subversion zainstalować, skonfigurować lokalny serwer, założyć repozytorium i utworzyć kopię roboczą pora na kolejny temat.

Podstawy pracy z wersjonowanymi plikami

1) Pobranie zmian wprowadzonych przez innych użytkowników
Jeśli korzystamy z lokalnego repozytorium, do którego tylko my mamy dostęp w zasadzie możemy ten krok pominąć. Jeśli jednak pracujemy wraz z innymi zaktualizowanie plików w naszej kopii roboczej jest już koniecznością. Choćby po to by nie pracować nad rzeczami, które ktoś mógł już zrobić.
Wykonujemy to za pomocą komendy:
svn update
Nie musimy już wpisywać adresu repozytorium - wszystkie potrzebne dane siedzą sobie we wspomnianych już katalogach .svn
Po wykonaniu tej komendy wyświetlone zostaną wszystkie zmiany w plikach w postaci:
svn update
A blabla.java
D foofoo.java
U barbar.java
C jakis.java
G zupelnieinny.java
Updated to revision 48.
Gdzie A oznacza dodany plik, D - skasowany, U - zmieniony, C - pliki w konflikcie (gdy pobrane zmiany dotyczą tego samego fragmentu pliku, który był edytowany lokalnie), G - połączony za pomocą komendy merge z innej linii rozwojowej. Dodatkowo otrzymujemy informację o numerze rewizji repozytorium.

2) Wprowadzanie zmian w plikach i folderach
Gdy mamy już najnowszą wersję plików możemy wykonać następujące czynności:

a) Dodanie pliku
Pliki dodajemy za pomocą polecenia:
svn add [plik(i) lub folder(y)]
Po wykonaniu tej komendy pliki zostaną oznaczone jako oczekujące na dodanie. Rzeczywiste dodanie nastąpi w momencie najbliższego commitu. Jeśli wskazany został folder cała jego zawartość również zostanie dodana do repozytorium.
Foldery możemy także utworzyć za pomocą polecenia
svn mkdir [folder]
Jeśli utworzymy pliki normalnymi poleceniami systemu i nie dodamy ich za pomocą svn add nie będą wersjonowane!

b) Usunięcie pliku
Pliki usuwamy za pomocą:
svn delete [plik(i) lub folder(y)]
Jeśli wybrany został plik natychmiast zniknie on z kopii roboczej, jeśli folder to zostanie on (i jego zawartość) oznaczone jako do usunięcia. Rzeczywiste usunięcie plików z repozytorium nastąpi, podobnie jak w przypadku svn add dopiero przy najbliższym commicie.
Jeśli skasujemy plik normalnymi poleceniami systemu a nie za pomocą svn delete zostaną ponownie pobrane z repozytorium przy najbliższym update. Warto o tym pamiętać - jeśli coś solidnie popsuliśmy wystarczy skasować "popsuty" plik lub folder i wykonać update by móc cieszyć się poprzednią wersją pliku.

c) Przenoszenie i kopiowanie plików
Wykonujemy za pomocą poleceń
svn move [źródło] [cel]
svn copy [źródło] [cel]
Co najważeniejsze SVN "pamięta" całą historię kopiowanego pliku. Podobnie jak w przypadku dodawania i kasowania plików trzeba wykonać commit by zmiany zostały zapisane w repozytorium.

d) Dokonywanie zmian w plikach
W wypadku zwykłych zmian w plikach nie musisz używać żadnych specjalnych komend Subversion. Po prostu edytujesz pliki w swoim ulubionym edytorze.

3) Sprawdzenie jakie zmiany zostały dokonane
Przed wysłaniem wyniku swojej pracy do repozytorium warto sprawdzić co tak na prawdę zmieniliśmy. Co najważniejsze wszystkie przedstawione w tym punkcie komendy nie wymagają połączenia z repozytorium. Wszystkie potrzebne dane znajdują się w katalogach .svn
Do tego celu możemy wykorzystać:

a) Wykaz zmian
Wykaz wszystkich zmienionych plików i folderów otrzymamy za pomocą polecenia:
svn status
Zwrócona zostanie lista plików poprzedzona sześcioma kolumnami informującymi o rodzaju zmian. Nas na razie interesuje jedynie pierwsza kolumna zawierająca oznaczenia podobne do tych poznanych w komendzie svn update
I tak: A - element przygotowany do dodania, D - element przygotowany do skasowania, U - element zmodyfikowany, R - zamieniony (element został przygotowany do skasowania a następnie został utworzony nowy o tej samej nazwie), ? - element nie podlegający wersjonowaniu (na przykład plik dodany normalnymi metodami a nie za pomocą svn add), ! - brakujący element (na przykład skasowany normalnymi metodami a nie za pomocą svn delete)

b) Wyszczególnienie zmian w pliku
Czasem może się zdarzyć, że nie pamiętamy jakich zmian dokonaliśmy w pliku. Pomocne wtedy jest polecenie:
svn diff
Zwraca ono listę zmian w plikach w formacie unified diff format

4) Cofnięcie zmian
Dopóki nie dokonaliśmy commitu możemy łatwo cofnąć wprowadzone w kopii roboczej zmiany. Używamy polecenia:
svn revert
svn revert [nazwa pliku]
Polecenie bardzo przydatne jeśli przez pomyłkę skasowaliśmy jakiś plik lub rozmyśliliśmy się jeśli chodzi o zmiany.

5) Pobranie aktualnych wersji plików
Tak, tak. Po raz kolejny wykonujemy update by sprawdzić czy nikt inny nie dokonał zmian w tych samych plikach co my. W większości wypadków Subversion bez problemu poradzi sobie z wprowadzeniem odpowiednich zmian. Problem pojawi się gdy okaże się, że ktoś edytował ten sam fragment pliku co my. Subversion nie jest w stanie samemu zaktualizować pliku i pojawia się konflikt (pamiętacie literkę 'C' w svn update?)

6) Rozwiązywanie konfliktów
W momencie powstania konfliktu Subversion tworzy 3 nowe pliki i modyfikuje plik będący w konflikcie. Trzy nowe pliki to:
plik.mine - wersja pliku z naszymi zmianami
plik.rOLDREV - gdzie OLDREV to numer rewizji sprzed naszych zmian
plik.rNEWREV - gdzie NEWREV to numer rewizji aktualnej wersji w repozytorium (ze zmianami wprowadzonymi przez kogoś innego)
W pliku będącym w konflikcie dopisane zostają dodatkowe linijki z zaznaczonym konflikotwym fragmentem w formie:
linia niezmieniona
<<<<<<< .mine
linia zmieniona przeze mnie
=======
linia zmieniona przez kogoś
>>>>>>> .rNEWREV
linie niezmieniona

Po skontaktowaniu się z osobą, która wprowadziła swoje zmiany poprawiamy plik by zawierał ostateczną wersję (edytując go odpowiednio lub używając jednego z 3 plików jako wzoru) i wykonujemy polecenie:
svn resolved [nazwa pliku]
Subversion przygotuje plik i konflikt zostanie rozwiązany przy najbliższym commicie. Przy okazji skasowane zostaną trzy dodatkowe pliki (.mine, rOLDREV, .rNEWREV)

7) Wysłanie zmian do repozytorium
Gdy mamy już aktualne wersje plików i nie ma konfliktów wreszcie możemy wysłać zmiany do repozytorium za pomocą polecenia:
svn commit
Przy wysyłaniu commitu musimy dodać komentarz z opisem, który zostanie dołączony do logów. Jeśli użyjemy polecenia commit w formie jak powyżej otworzy się domyślny edytor tekstu, w którym możemy wpisać komentarz. Możemy również użyć polecenie w formie:
svn commit -m "treść komentarza"
Rzecz jasna by wykonać to polecenie musimy nawiązać połączenie z repozytorium.

W tym momencie możemy rozpocząć nasz cykl pracy od początku.


O kolejnych, bardziej zaawansowanych funkcjach Subversion w kolejnych odcinkach cyklu.
piątek, 07 grudnia 2007
1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word

Instalacja Subversion

By zainstalować Subversion na naszym komputerze wchodzimy na stronę projektu, wybieramy dział download by pobrać i uruchomić instalator dla naszego systemu operacyjnego. Instalator prowadzi za rękę i nie powinno być z tym najmniejszego problemu.

Lokalny serwer Subversion

Mamy tutaj dwie możliwości:
  • dostęp za pomocą protokołu svn bezpośrednio do serwera SVN
  • dostęp za pomocą protokołu HTTP lub HTTPS z wykorzystaniem serwera Apache
Każde z tych rozwiązań ma swoje wady i zalety (są dokładnie opisane w dokumentacji). Ja wybrałem rozwiązanie prostsze czyli dostęp bezpośredni do serwera.
W zasadzie można również wykorzystać bezpośredni dostęp do plików repozytorium, jednak jest to zdecydowanie niepolecane rozwiązanie.

Serwer Subversion jako usługa Windows

Dzięki zarejestrowaniu serwera SVN jako usługi Windows nie musimy pamiętać aby za każdym razem uruchamiać serwer. Uruchomi się wraz ze startem systemu. Wystarczy w konsoli wpisać:
> sc create svn
binpath= "[ścieżka katalogu SVN]\bin\svnserve.exe --service -r [ścieżka do katalogu z repozytoriami]"
displayname= "Subversion Server"
depend= Tcpip
start= auto
Jeśli zainstalowaliśmy SVN w Program Start trzeba wpisać ścieżkę w ten sposób:
binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r [ścieżka do katalogi z repozytoriami]"
i gotowe! [ścieżka do katalogi z repozytoriami] to katalog, w którym będziemy tworzyć repozytoria dla poszczególnych projektów, np: D:\SVN-repos

Utworzenie repozytorium

Skoro serwer już działa czas na utworzenie repozytorium. Udajemy się do katalogu w którym będziemy tworzyć repozytoria (tu niech będzie to D:\SVN-repos) i wykonujemy:
D:\SVN>svnadmin create [nazwa repozytorium]
Jeśli wszystko działa jak należy utworzony został folder o nazwie takiej jak nazwa repozytorium. Teraz pora ustawić prawa dostępu do repozytorium. Wchodzimy do katalogu z repozytorium, do katalogu conf i edytujemy następujące pliki:
W pliku svnserve.conf w części [general] powinno się znaleźć:
[general]
anon-access = read
auth-access = write
password-db = passwd
A w pliku passwd dopisujemy:
[login] = [hasło]

Import projektu do repozytorium

Cóż ro za repozytorium bez wersjonowanych plików. Tu pojawia się ważna kwestia układu plików w repozytorium (lub repozytoriach)
1. Wspólne repozytorium dla wielu projektów
To rozwiązanie jest dobre dla projektów, które są ściśle ze sobą powiązane. Pliki w repozytorium mogą być ułożone tak:

Projekt1/
    trunk/
    tags/
    branches/
Projekt2/
    trunk/
    tags/
    branches/

lub tak:

trunk/
    Projekt1/
    Projekt2/
tags/
    Projekt1/
    Projekt2/
branches/
    Projekt1/
    Projekt2/

Trzeba pamiętać, że numery rewizji są wspólne dla całego repozytorium. To znaczy każdy commit zwiększa numer o jeden bez względu na to, którego projektu dotyczy. Z drugiej strony uzyskujemy dużą łatwość w przenoszeniu plików pomiędzy projektami.

2. Osobne repozytorium dla każdego projektu
Rozwiązanie korzystne dla niezależnych projektów. Numery rewizji zmieniają się tylko w obrębie projektu. Tworzymy wtedy repozytorium o nazwie takiej jak nazwa projektu i zaimportujemy katalogi:
trunk/
tags/
branches/

Jeśli chcemy zaimportować do repozytorium istniejący już projekt najlepiej umieścić istniejące pliki w folderze trunk
By zaimportować pliki przechodzimy do katalogu głównego projektu (czyli np: D:\Projekty\projekt1 gdzie znajdują się katalogi trunk\[pliki projektu] , tags\ i branches\) i wykonujemy polecenie:
svn import svn://localhost/[nazwa repozytorium] -m 'Initial import'
gdzie po -m wpisaliśmy komentarz, który pojawi się w logu. Jeśli nie dodamy -m '[Komentarz]' pojawi się okienko Notatnika (lub innego domyślnego edytora tekstu), gdzie będziemy mogli wpisać komentarz.

Utworzenie kopii roboczej

Pliki mamy już w repozytorium. Pora utworzyć kopię roboczą.

UWAGA!
Jeśli nie jesteśmy pewni czy wszystko robimy dobrze najpierw przetestujmy przedstawione komendy na dowolnych plikach a nie od razu na ważnych dla was plikach. Jeśli nie jesteś pewien zawsze możesz wykonać polecenia svn help i svnadmin help by poznać szczegóły działania komend. Żeby potem nie było na mnie jeśli coś pójdzie nie tak i stracicie ważne dane!

Kasujemy folder zawierający projekt. Przechodzimy do folderu, w którym ma się znaleźć kopia robocza (np: D:\Projekty\) i wykonujemy polecenie:
svn checkout svn://localhost/[nazwa repozytorium]/trunk [nazwa projektu]
Utworzony zostanie folder o nazwie [nazwa projektu] zawierający wszystkie pliki z katalogu trunk z repozytorium (czyli wszystkie zaimportowane wcześniej pliki). Warto zauważyć, że we wszystkich wersjonowanych folderach pojawił się ukryty folder .svn zawierający wszystkie dane potrzebne do właściwego wersjonowania plików.


Ufff.... Jako, że wpis zrobił się o wiele dłuższy niż przewidywałem podstawowe komendy i opis sposobu korzystania z wersjonowanych plików w następnym odcinku.
czwartek, 06 grudnia 2007

1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word

Subversion

W jednym z poprzednich wpisów pisałem o pożytkach z systemu kontroli wersji. Dziś, zgodnie z zapowiedzią, słów kilka o Subversion (w skrócie SVN). Dlaczego akurat ten system, a nie któryś ze sporej rzeszy konkurentów? Ponieważ SVN jest:

  • darmowy
  • wieloplatformowy
  • stosunkowo prosty w obsłudze
  • popularny
  • open-source'owy
  • istnieje wiele programów oferujących wsparcie dla SVN i ułatwiających pracę z tym systemem kontroli wersji
  • jest dużo materiałów poświęconych SVN (a ten wpis jest kolejnym z nich)
  • łatwo skonfigurować własny serwer SVN (lub jako rozszerzenie dla Apache'a)

Na początek wypadałoby się zapoznać z terminologią.

Słowniczek podstawowych pojęć

  • Repozytorium (repository) - foldery i pliki znajdujące się na serwerze SVN. Zawiera całą historię zmian (kolejne rewizje). Można powiedzieć, że to taki system plików z dodatkowym wymiarem - czasem.
  • Rewizja (revision) - stan systemu plików po wykonaniu określonej liczby commitów. Oznaczany kolejnymi numerami. Każdy commit powoduje zwiększenie numeru wersji o 1. W celu oszczędzania miejsca i ilości przesyłanych danych wysyłane, pobierane i składowane są jedynie różnice pomiędzy plikami.
  • Head - najnowsza rewizja (powstała po ostatnim commicie).
  • Kopia robocza (working copy) - zestaw plików pobranych z repozytorium, mogą pochodzić z dowolnej gałęzi, czy też rewizji. Zmian na plikach dokonujemy pracując na kopii roboczej, w każdej chwili możemy cofnąć wszelkie zmiany, wysłać je do repozytorium lub pobrać aktualizację plików z repozytorium.
  • Checkout - pobieranie plików z repozytorium w celu utworzenia kopii roboczej.
  • Trunk (gałąź główna) - główna linia rozwojowa projektu. Przyjmuje się, że pliki w głównej gałęzi powinny się kompilować.
  • Branch (gałąź rozwojowa) - kopia plików, która będzie podlegać alternatywnej ścieżce rozwoju. Na przykład chcąc zmodyfikować pojedynczy moduł lub rozwiązując jakiś problem tworzymy osobny branch, a później scalamy dokonane tam zmiany z główną linią rozwojową (trunk).
  • Tag (etykieta) - kopia plików będąca jakby "zdjęciem" (snapshot) systemu plików w określonej wersji. Taguje się na przykład stan systemu dla kolejnych wydań. Zwyczajowo tagi traktuje się jako read-only (tylko do odczytu).
  • Switch - zmiana gałęzi lub wersji plików w kopii roboczej (np z trunk do którejś z gałęzi rozwojowych).
  • Update - pobranie zmian pomiędzy aktualną kopią w repozytorium a kopią roboczą i aktualizacja plików kopii roboczej.
  • Commit - wysłanie do repozytorium lokalnie dokonanych zmian (w kopii roboczej) - aktualizacja plików w repozytorium.
  • Scalanie (merge) - scalanie zmian dokonanych w różnych gałęziach rozwojowych.
  • Kolizja (collision) - sytuacja w której równolegle dokonano różnych zmian w tym samym fragmencie pliku i SVN nie jest w stanie dokonać samodzielnie scalenia plików. Należy wtedy zdecydować, która ze zmian jest właściwa.
  • Właściwości (properties) - dodatkowe właściwości dla plików i katalogów znajdujących się w repozytorium. Przykładem może być atrybut svn:ignore zawierający listę plików/folderów nie podlegających wersjonowaniu, czy też svn:author zawierający autora zmiany.
  • Log - dziennik zmian, wraz z komentarzami. Pozwala na śledzenie kto wprowadził zmiany, jakie i kiedy.

Na dzisiaj chyba wystarczy. W kolejnym odcinku o instalacji Subversion i podstawowych komendach.

Linki:
http://subversion.tigris.org/ - strona główna projektu Subversion
http://svnbook.red-bean.com/ - oficjalny podręcznik SVN
http://en.wikipedia.org/wiki/Revision_control - najważniejsze pojęcia w systemach kontroli wersji
http://en.wikipedia.org/wiki/Subversion_(software) - o SVN w wiki
http://www.gajdaw.pl/varia/subversion-system-kontroli-wersji-tutorial/ - poradnik o SVN oraz TortoiseSVN

piątek, 30 listopada 2007

1. Wersje pod kontrolą - wstęp do wersjonowania plików
2. Subversion - podstawowe pojęcia
3. Subversion - instalacja i tworzenie repozytorium
4. Subversion - podstawy pracy z wersjonowanymi plikami
5. Subversion - zaawansowane komendy
6. TortoiseSVN - graficzny klient SVN
7. RabbitVCS + Meld - integracja Subversion z Nautilusem
8. VisualSVN Server - prosta instalacja serwera Subversion
9. SVN4MSOffice - potęga Subversion w MS Word

Kontrola wersji

Brzmi groźnie. Jestem jednak przekonany, że każdy użytkownik komputera stosował już jakiś (choćby najprostszy) sposób na kontrolowanie wersji. No dobra, ale po co coś takiego w ogóle stosować?

  • gdy chcemy wiedzieć jakie zmiany i kiedy wprowadzaliśmy do danego pliku
  • gdy chcemy mieć łatwy dostęp do poprzednich wersji plików (np gdy coś "popsujemy" w aktualnie edytowanej wersji)
  • gdy chcemy porównywać różne wersje tego samego pliku

Jest to szczególnie ważne w przypadku wszelkich prac programistycznych, pisania jakichś ważnych dokumentów, nad którymi pracujemy przez dłuższy czas.

Najprostsze rozwiązania

  • zapisywanie kolejnych wersji dokumentu jako osobne pliki z numerem zmiany w nazwie. Na przykład dodając do nazwy pliku "_XX" (gdzie XX to numer). Ewentualnie dopisując aktualną datę
  • jeśli edytujemy wiele plików na raz możemy tworzyć kolejne wersje kopiując pliki do osobnych folderów z datą w nazwie
  • można sobie ułatwić życie wspomagając się prostymi skryptami jak w przykładzie na LifeHacker

Jest to rozwiązanie niezmiernie proste i stosowane przez wielu użytkowników. Sprawdzi się stosunkowo dobrze przy edycji pojedynczego dokumentu, lub małej ich liczby. W pozostałych przypadkach odczujemy jego wady:

  • mimo prostoty, jest to rozwiązanie dość żmudne. Musimy ręcznie kopiować pliki i zmieniać ich nazwy (o ile nie użyjemy skryptów automatyzujących tą pracę)
  • na dłuższą metę bardzo łatwo się pogubić
  • pliki zajmują coraz więcej miejsca. Trochę pomoże kompresowanie plików, jednak jest to dodatkowa czynność jaką należy wykonać i utrudnia to dostęp do wersjonowanych plików
  • by zobaczyć jakie zmiany wprowadziliśmy musimy zastosować dodatkowe narzędzia (np diff)
  • utrudnione przemieszczanie się pomiędzy poszczególnymi wersjami (np cofnięcie się kilka wersji w tył, wprowadzenie kilku zmian i połączenie tych zmian z wersją najnowszą)
  • bardzo trudno dodawać dodatkowe komentarze opisujące co zmieniliśmy w dokumencie
  • bardzo trudne jest sprawdzanie kiedy dodaliśmy lub skasowaliśmy, któryś z wersjonowanych plików

Dodatkowo pojawiają się problemy z pracą grupową:

  • gdy chcemy mieć pewność, że wszyscy edytujący pliki mają dostęp do ich najnowszych wersji
  • gdy chcemy wiedzieć kto wprowadził dane zmiany
  • gdy chcemy ograniczyć do minimum ilość przesyłanych danych pomiędzy edytującymi

By rozwiązać opisane problemy stworzono wiele systemów kontroli wersji. W kolejnym wpisie opisze jeden z najpopularniejszych - Subversion.

Spis Treści
Kanały RSS
Add to Google
Add to Netvibes