W każdym większym CVSie, projekty główne rozgałęziają się tworząc tzw. branche - W przypadku PLD np. istnieje stabilny, lecz już troche leciwy branch "RA-branch", który wywodzi się z brancha głównego HEAD. W pewnym momencie RA-branch został "zamrożony" i dokonywane są na nim tylko zmiany zawierające poprawki poważnych błędów lub aktualizacje związane z bezpieczeństwem. Branch HEAD "żyje" dalej i są w nim dokonywane zmiany i powstają nowe pakiety. Odgałęzień może być (i jest) wiele, co na początku troche gmatwa spojrzenie na CVS ale później doceniamy zalety tego rozwiązania. Dane odnogi mają przydzielone odpowiednie etykiety "lepkie" (ang. sticky tag) - czyli etykieta jest przekazywana każdej następnej wersji w danej odnodze. Zwykłe etykiety (ang. tag) możemy użyć np. do okreslenia indywidualnego stanu danego pliku - określając np. tag STABLE, UNSTABLE lub DEVELOP.

Jeżeli chodzi o etykietowanie to trzeba zachować rozwagę. Musimy być pewni że wiemy co chcemy osiągnąć, bo możemy popsuć pracę komuś innemu (dotyczy to także zmian w cudzych specach).

Praktycznie najczęściej wykorzystywane są następujące opcje związane z odnogami i etykietami:

$ cvs status -v mldonkey.spec // Statystyka odnóg i etykiet =================================================================== File: mldonkey.spec Status: Up-to-date Working revision: 1.14.2.8 // Rewizja (wersja) robocza na lokalnym CVS Repository revision: 1.14.2.8 /cvsroot/SPECS/mldonkey.spec,v // Rewizja na zdalnym CVS Sticky Tag: RA-branch (branch: 1.14.2) // Dane dotyczące lepkiej etykiety - związanej z branchem (odnogą) Sticky Date: (none) Sticky Options: (none) Existing Tags: // Istniejące etykiety zwykłe mldonkey-2_5_3-2 (revision: 1.14.2.7) STABLE (revision: 1.14.2.7) mldonkey-2_5-1 (revision: 1.14.2.2) RA-branch (branch: 1.14.2) $

Sam sposób robienia odnóg pozostawiam innym - lepiej poczytać np. opis CVS PLD bo sam tego jeszcze nie robiłem :). Etykietowanie możemy wykonać np.: mając plik w naszym lokalnym repozytorium wydajemy polecenie:

cvs tag UNSTABLE plik.spec

czyli plik.spec otrzymał etykietę UNSTABLE.

Ostatnim przykładem będzie przenoszenie zmian między odnogami (branchami). Robiąc jakiś spec w głównej odnodze HEAD doszliśmy do wniosku, że zmiany można ogłosić w odnodze RA-branch. Można spróbować wykonać polecenie:

cvs update -r RA-branch -j HEAD mldonkey.init

ale najczęściej różnice między wersjami w odnogach są tak duże, że otrzymamy komunikat o braku automatycznej możliwości przeniesienia zmian. Wtedy można rozwiązać ten problem innym sposobem. Tworzymy np. w podkatalogu "SPECS" katalog "RA-branch" (nazwa katalogu jest nieistotna, ale pomocna). W podkatalogu "RA-branch" wykonujemy:

$ cvs get -A SPECS/plik.spec // parametr "A" usuwa tag $ cd SPECS $ cvs tag -b RA-branch plik.spec // nowy tag dla odnogi RA-branch $ cp z_HEAD_plik.spec // podmieniamy plik na właściwy z HEAD $ cvs commit -r RA-branch plik.spec // zatwierdzamy zmiany jako RA-branch $

Myślę że komentarze są czytelne. Gdy zrobimy co najmniej jedną taką operację, to istniejący katalog RA-branch może nam służyć do późniejszych operacji kopiowania zmian między odnogami (np. korzystając z opcji "cvs up".