| W krainie CVS - czyli wielki kocioł Umiemy już w miare klecić nowe spece, naprawiać
stare - chcemy dołączyć do drużyny PLD... Musimy mieć więc możliwość
pogrania na boisku, a nie tylko zasiadać na trybunach jako widz. Naszym
boiskiem będzie CVS a możliwość czytania i pisania do niego (Read-Write)
naszym sposobem na grę :) Żeby otrzymać własne konto CVS należy uzyskać poparcie już aktywnych deweloperów. Zwykle osoby wykazujące się aktywnością na listach dyskusyjnych (podsyłające patche, itp.) prędzej czy później są wręcz proszone o zgłoszenie się po konto. W typowym przypadku wystarczy, że trzech deweloperów wyrazi poparcie kandydata na dewelopera (trzeci z nich powinien wskazać mu dokąd powinien się zgłosić po konto). Osoba popierająca kandydata jednocześnie staje się jego opiekunem i nadzoruje jego działania w początkowej fazie. W przypadku gdyby, mimo poparcia przez niektórych, osoba kandydata wywoływała kontrowersje, decyzja o jego przyjęciu (lub nie) będzie podjęta zgodnie z obowiązującą procedurą rozwiązywania konfliktów. Kiedy już zostaniemy przyjęci, po pierwsze musimy sobie wymyśleć ksywke i hasło. Potem z linii poleceń wykonujemy jednolinijkowe polecenie - wstawiając za login i haslo odpowiednie dane: perl -e 'print "login:" . crypt("haslo", join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64]) . "\n"' w wyniku którego otrzymamy ciąg znaków podobny do: login:/APGG.cfeqPpk Ciąg ten kopiujemy do listu e-mail z prośbą o możliwość
RW na CVS PLD i wysyłamy na adres cvsadmin@pld-linux.org
Czyli pierwsze formalności mamy za sobą. Możemy już działać na CVS. Jednak proponuje znowu trochę teorii - tym razem zdecydowana większość dokumentacji jest w języku angielskim. Mamy więc bardzo dobry, oficjalny podręcznik CVS (uwaga ponad 800KB), książke kucharską CVS (uwaga ponad 600KB) - jest także opis po polsku - stworzony przez developerów PLD, a także książka z cyklu leksykon kieszonkowy "CVS" Gregor N. Purdy (koszt ok. 10PLN) - tak więc jest w czym wybierać. Jeszcze raz zwróćmy uwagę na maila którego otrzymaliśmy. Jest tam coś o dopisaniu "users". Musimy wykonać zalecenie. Aby to zrobić musimy znowu przygotować sobie środowisko CVS - albo modyfikując istniejące, dotychczasowe konto "anonymous" albo tworząc od początku środowsko w nowym katalogu. Ja wybrałem pierwszy sposób (troche wbrew zaleceniom z dokumentacji - ale za to szybszy), polega on na modyfikacji każdego pliku "Root" w podkatalogach "CVS" - należy tam wpisać fraze: :pserver:<nasz_login>@cvs.pld-linux.org:/cvsroot Czyli w naszym przypadku wchodzimy do katalogu ./rpm
i wchodzimy do każdego podkatalogu "CVS" i zmieniamy ręcznie
plik "Root" - nie ma w tej chwili tych katalogów wiele,
więc nie powinno to sprawić kłopotu. Następnie możemy już spróbować zalogować się do CVS PLD:
Wpisujemy hasło które wymyśleliśmy i jesteśmy zalogowani. Każdy komunikat błędu oznacza że coś wcześniej źle wykonaliśmy, albo że np. nie działa sieć. Login wykonujemy praktycznie raz i dopóki nie wykonamy polecenia "cvs logout" jesteśmy ciągle gotowi do pracy. Czas już zabrać się za plik "users"
Do naszego lokalnego repozytorium, do katalogu CVSROOT ściągneliśmy plik users, który służy w PLD do wpisania aliasu pocztowego - przy okazji możemy zobaczyć w jakim towarzystwie przyjdzie nam pracować :) nasz_login:użytkownik_mail@domena_naszego_email:Imie i Nazwisko Edytujemy odpowiednio więc plik user - wystarczy tylko drobna znajomość alfabetu i robimy nasz pierwszy commit - czyli potwierdzamy zmiany.
Po wydaniu polecenia cvs ci CVSROOT/users otworzy się nasz ulubiony edytor i pojawi się coś podobnego do:
Właśnie dokonaliśmy pierwszej zmiany w repozytorium PLD. Od tej chwili każdy mail adresowany na <nasz_login>@pld-linux.org trafi na naszą skrzynkę pocztową. Dalsza część naszych rozważań będzie już w formie konkretnych przykładów, ponieważ to co chcemy zrobić w repozytorium CVS PLD zależy od konkretnych potrzeb. Od tej chwili nikt już nas za rączke nie będzie prowadził, a czekają nas pot, krew, łzy i pierwsze "recenzje" naszych poczynań - np. na grupie PLD-devel czy kanale #PLD - a jedynymi nagrodami będzie brak tych recenzji, zdobyta wiedza, satysfakcja i działające paczki, których przez chwilę nikt na świecie nie będzie miał :) Każdy nowy plik, który chcemy umieścić w repozytorium należy dodać za pomocą polecenia "cvs add"
Jak widać z komentarza, aby zakończyć dodanie pliku należy zatwierdzić zmianę za pomocą polecenia "cvs ci" (polecenia podaje w formie skróconej) - Samo zatwierdzanie (commit) robiliśmy już wcześniej przy okazji pliku "users". Pliki możemy zaktualizować względem CVS - jeżeli
nasz plik jest nowszy nie zostanie dokonana żadna zmiana na naszym
lokalnym repozytorium. Aktualizacją nie dokonujemy zmian na zdalnym
repozytorium.
W powyższym przykładzie dokonaliśmy aktualizacji pliku "python.spec". Literka "P" określa stan aktualizacji. Poniżej przedstawie możlwe kody: - "A" - Plik
dodany. Oznacza że na pliku dokonano operacji "ADD"
(czyli dodanie do repozytorium) ale nie wykonano commitu (zatwierdzenia) Zatwierdzanie zmian i Distfiles Sam przykład zatwierdzania zmian mogliśmy poznać
wcześniej. Jest to najczęściej wykonywana operacja na CVS. Oto przykłady użycia ./builder z odpowiednimi opcjami:
Opcje "5" i "U" są podobne, z tym że "5" próbuje poprawić md5 korzystając z istniejącego sources w lokalnym repozytorium. Natomiast "U" próbuje zawsze ściągnąć źródła z podanego przez spec URL. Taka jest teoria. Ja praktycznie używam opcji "U" kasując wcześniej źródła z lokalnego repozytorium, ponieważ w innym przypadku wyskakują dziwne błędy o konflikcie z parametrem -nd
W każdym większym CVSie, projekty główne rozgałęziają
się tworząć 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 spojżenie 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. Praktycznie najczęściej wykorzystywane są następujące opcje związane z odnogami i etykietami:
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:
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". - updated to version 2.5.3. Release 1 STBR for RA update general STBR jest skrótem od "Send To Builder Request" |