Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

System kontroli wersji plików w codziennych zastosowaniach

Podczas grupowej pracy nad dokumentami lub innymi projektami często zdarza się, że dwie osoby w tym samym czasie pracują nad tą samą rzeczą. W najlepszym wypadku niepotrzebnie podwajają pracę, w najgorszym wzajemnie niszczą swoje dokonania. Również podczas indywidualnej pracy nad poważniejszymi plikami często przydaje się możliwość podglądu historii zmian i ewentualnego przywrócenia poprzednich wersji. W takich sytuacjach można wykorzystać prosty, ale efektywny system kontroli wersji RCS – Revision Control System.

Ogólnie rzecz biorąc system kontroli wersji można porównać do szuflady. Jeżeli dany plik znajduje się w tej szufladzie (jest „zameldowany” – check in) można go z niej wyciągnąć („wymeldować”, check out) w celu wprowadzenia odpowiednich zmian. W tym czasie plik jest blokowany do edycji dla innych użytkowników. System jednocześnie sprawdza nasze poczynania i skrupulatnie je rejestruje. Ułatwi to później śledzenie historii zmian lub ewentualne przywrócenie ostatniej działającej wersji,

Skoro znamy ogólną zasadę działania systemu kontroli, należy się upewnić że RCS został zainstalowany na naszej maszynie. We FreeBSD jest domyślnie instalowany razem z systemem, w Linuksie można łatwo zainstalować odpowiedni pakiet z repozytorium. Wydanie w terminalu komendy rcs wyjaśni sprawę.

Aby zgłosić plik do systemu należy wydać polecenie ci (check in). Przy pierwszym uruchomieniu system poprosi o wpisanie opisu dla pliku i zarejestruje go jako wersję 1.1.jakub@debian:~/Dokumenty/Blog/Szkice$ ci RCS.odt RCS.odt,v > Szkic artykułu o systemie kontroli wersji na blog DP >> . initial revision: 1.1 doneOkno menedżera plików lub komenda ls pokaże nam, że plik RCS.odt zniknął, a w jego miejsca powstał RCS.odt,v. Jest to właśnie nasza szuflada, w której będą przechowywane kolejne wersje dokumentu. Pliku RCS.odt,v nie można edytować bezpośrednio.

Jeżeli chcę teraz otworzyć plik do edycji muszę wyciągnąć go z tej szuflady, czyli wymeldować z systemu kontroli. Dokonuje się to poprzez komendę co (check out; flaga -l dodatkowo blokuje ten plik do edycji wyłącznie dla osoby wywołującej):jakub@debian:~/Dokumenty/Blog/Szkice$ co -l RCS.odt,v RCS.odt,v --> RCS.odt revision 1.1 (locked) doneOd tego momentu mogę spokojnie edytować plik. Po zakończeniu z powrotem wkładam go do szuflady za pomocą komendy ci. Analogicznie system poprosi nas o komentarz dotyczący wprowadzonych zmian i nada odpowiedni numer wersji.

Załóżmy, że zostawiliśmy później otwarty plik i poszliśmy zaparzyć kawę. Jeżeli dzielimy pokój w akademiku lub mieszkamy z żoną i dziećmi, wiemy jak destruktywne potrafią być skutki takiej niefrasobliwości (swoją drogą zaśnięcie przy klawiaturze też czyni cuda). Wracamy przed ekran, a zamiast wspaniałego elaboratu znajdujemy czysty, świeżo zapisany plik lub ciąg losowych znaków. Na szczęście nie ma dramatu. Wystarczy przejrzeć, która z ostatnich wersji pliku najbardziej nam odpowiada i przywrócić ją do użytku. Do ogólnego przeglądania historii zmian służy polecenie rlog:jakub@debian:~/Dokumenty/Blog/Szkice$ rlog RCS.odt RCS file: RCS.odt,v Working file: RCS.odt head: 1.2 branch: locks: strict jakub: 1.2 access list: symbolic names: keyword substitution: kv total revisions: 2; selected revisions: 2 description: Szkic artykułu o systemie kontroli wersji na blog DP ---------------------------- revision 1.2 locked by: jakub; date: 2010/04/17 11:13:13; author: jakub; state: Exp; lines: +73 -71 dopisałem kilka kolejnych zdań. ---------------------------- revision 1.1 date: 2010/04/17 11:01:10; author: jakub; state: Exp; Initial revision

Wygląda na to, że wersja 1.2 będzie odpowiednia. Można ją przywrócić za pomocą co ze wskazaniem na konkretną wersję: jakub@debian:~/Dokumenty/Blog/Szkice$ co -r1.2 RCS.odt RCS.odt,v --> RCS.odt revision 1.2 writable RCS.odt exists; remove it? [ny](n): y done W łatwy sposób zaoszczędziliśmy sobie trochę nerwów. Przykład jest oczywiście banalny, ale w przypadku pisania pracy licencjackiej czy magisterskiej pełna kontrola nad wersjami jest szczególnie ważna. RCS przydaje się również podczas edycji plików systemowych. Dzięki temu jeżeli coś popsujemy można w prosty sposób przywrócić ostatnią działającą wersję. Ponadto można prześledzić wiersz po wierszu zmiany, które zostały wprowadzane podczas kolejnych edycji. Do tego ostatniego zadnia służy polecenie rcsdiff.

W przypadku plików systemowych powstaje jednak problem, ponieważ nie mogą one po prostu zniknąć w szufladzie i muszą być dostępne cały czas w systemie. Nie mogę sobie na przykład pozwolić żeby zniknął plik /etc/network/interfaces (w Linuksie) lub /etc/rc.conf (we FreeBSD). System nie będzie działał działał poprawnie, jeżeli zamiast tych plików znajdzie jedynie pliki kontroli wersji, np.: rc.conf,v. W takim wypadku meldując plik w systemie należy użyć opcji -u, która zostawia kopię pliku na swoim miejscu. Z systemem kontroli wersji można śmiało grzebać pod maską systemu bez strachu o konsekwencje. Happy hacking ;-) 

Komentarze

0 nowych
n-pigeon   5 #1 17.04.2010 18:12

Nie lepiej urzyć czegoś nowszego? Gita, SVN lub chociażby CVS, który zdaje się bazuje na RCSie?

skandyn   9 #2 17.04.2010 18:35

Bardzo ciekawy artykuł i zakończenie - Happy hacking. Proszę poprawić „pliki kotroli wersji”.
Pozdrawiam.

iacobus   6 #3 17.04.2010 18:56

n-pingeon: pewnie, że można i trzeba używać nowszych narzędzi. RCS jest jednak prosty jak budowa cepa, więc doskonale nadaje się jako przykład.
skandyn-dzięki za info!

piszczyk4U43   3 #4 17.04.2010 19:10

> Podczas grupowej pracy nad dokumentami lub
> innymi projektami często zdarza się, że dwie osoby
> w tym samym czasie pracują nad tą samą rzeczą

To znaczy, że praca/projekt jest źle zorganizowana :)

@skandyn:
nie zauważyłeś "chek in" :)

n-pigeon   5 #5 17.04.2010 19:19

@ iacobus

W sumie racja :)

Od siebie dodam że systemy kontroli wersji świetnie sprawdzają się również przy projektach graficznych. Graficy tworzący animacje w projekcie Durian i Tube, używają tego typu oprogramowania.

penguin   6 #6 17.04.2010 19:25

@iacobus
zastanawiam się właśnie nad czymś podobnym o czym piszesz.
mianowicie przeniesienie moich wszystkich dokumentów "w obszar repozytorium".

masz z tym jakieś doświadczenia? jaki system kontroli (i ewentualnie jaka nakładka do niego ułatwiająca tego typu jego zastosowanie) będzie subiektywnie według Ciebie najlepsza?

iacobus   6 #7 17.04.2010 21:04

piszczyk - dzięki poprawione
penguin - Większość osób poleca Subversion, tam nasz np. Bazaar.

iacobus   6 #8 17.04.2010 21:05

http://doc.bazaar.canonical.com/explorer/en/ Version Control for Human Beings

borzole   4 #9 18.04.2010 00:24

uproszczając rzeczy proste:

$ cat /usr/local/bin/ver.sh
#!/bin/bash
[ $# -eq 0 ] && { echo "Użycie: ${0##*/} plik" ; exit 0 ; }
ci "$1" && co -l "$1",v

Airborn   8 #10 19.04.2010 10:42

Jest jeden problem, pliki .odt są binarne (tzn niby coś tam można odczytać, ale ogólna struktura takiego dokumentu po otworzeniu w zwykłym edytorze tekstu jest zupełnie bez sensu). Co za tym idzie tracimy całą maskę funkcjonalności jaką zyskaliśmy dzięki kontroli wersji. Wniosek? Czas przerzucić się na LaTeXa!

  #11 23.09.2010 13:23

Polecam tworzenie w katalogach, w których używamy rcs-a, podfolderów RCS. Wówczas pliki wersji *,v będą trafiały właśnie tam, nie tworząc bałaganu w naszym folderze roboczym.

  #12 23.09.2010 14:49

Napisałem dziś prosty skrypcik dla crona, który będzie kopiował plik konfiguracyjny firewalla do katalogu roota, zapisując wersję w RCS, jeśli plik uległ zmianie. Jeśli się komuś przyda, to proszę bardzo:

#!/bin/bash
co -l /root/sysconf/firewall
cp /etc/fw/firewall /root/sysconf/
ci -m"Firewall configuration copy `date`" -u /root/sysconf/firewall

rafradek   2 #13 17.02.2011 17:41

Pliki .odt podobnie jak i .doc można otwierać w programach do pakowania. Otwarte w ten sposób dokumenty zawierają pliki XML i użyte obrazy.