Copyright © 2003-2006 Bartosz Feński aka fEnIo
Podręcznik ten dostępny jest na licencji GNU FDL (Free Documentation License). Został on napisany w nadziei, że będzie użyteczny dla społeczności użytkowników Debiana chcącej uczestniczyć w projekcie PDDP. Nie udziela się na niego żadnej gwarancji; używaj go wyłącznie na własne ryzyko.
.data
Linux jest nowoczesnym, wielozadaniowym, wieloużytkownikowym i
darmowym systemem operacyjnym. W dodatku dystrybuowany jest wraz z kodem
źródłowym. Każdy system jest jednak prawie całkowicie bezużyteczny bez
oprogramowania, które może na nim pracować. Dlatego też system Linux udostępniany jest w formie
dystrybucji, które stanowią połączenie jądra systemu oraz pełnego zestawu
oprogramowania. Jedną z takich dystrybucji jest Debian GNU/Linux, który może poszczycić
się największą ilością pakietów, czyli programów udostępnionych w formie łatwej
do zainstalowania.
Bardzo istotną częścią każdego systemu operacyjnego jest dokumentacja, która dostarcza niezwykle cennych i aktualnych informacji na temat konfiguracji wielu usług i programów. System Debian jest wręcz wzorem do naśladowania w tym zakresie. Jednakże, jako iż jest projektem międzynarodowym, większość dokumentacji z nim dostarczanej powstaje w języku angielskim, a nie każdy potrafi się nim posługiwać.
Dlatego właśnie powstała nasza grupa. Celem Polish Debian Documentation Project (w skrócie PDDP) jest spolszczenie dokumentacji dostarczanej wraz z systemem operacyjnym Debian GNU/Linux.
Jesteśmy grupą otwartą na nowych uczestników. Każdy może pomóc w tworzeniu polskiej dokumentacji Debiana. Projekt ma charakter non-profit, więc nie ma co liczyć na jakieś korzyści materialne z tytułu uczestnictwa w nim. Jednakże jest wiele powodów dla, których warto się przyłączyć. Poniżej tylko te ważniejsze:
Podczas tłumaczenia/poprawiania z pewnością nauczysz się czegoś nowego.
Uczestnicząc w projekcie chcąc nie chcąc integrujesz się z grupą. A jej członkami są ludzie z bardzo szerokim spektrum umiejętności i zainteresowań. Gdy będziesz mieć z czymś problem z pewnością spojrzą na Ciebie przychylniej.
Fakt brania udziału w projekcie można umieścić w swoim CV. Dla pracodawcy z pewnością istotne będzie, że pracownik udziela się w tego typu przedsięwzięciach.
Twój wkład na pewno zostanie doceniony przez środowisko informatyczne, a Ty będziesz mieć swój udział w kształtowaniu wizerunku systemu Linux w Polsce.
Dziewczyny (lub mężczyźni, jeśli jesteś kobietą) będą rywalizowały o Twoje względy. Na ulicy będą Cię rozpoznawać i prosić o autografy, a popularności będzie mógł Ci pozazdrościć sam wielki Gulczas ;)
Dodatkowo każdy uczestnik projektu ma prawo do skrzynki pocztowej (lub aliasu) w domenie debian.linux.org.pl. Więcej informacji w rozdziale Domena debian.linux.org.pl.
Nic nie szkodzi!
Jak pisałem wcześniej, pomóc może każdy. Przywiązujemy wielką wagę do poprawności naszych tłumaczeń. Dlatego, też istotne jest by przetłumaczone dokumenty były czytane przez jak największą liczbę osób. To miejsce właśnie dla Ciebie.
Przyłącz się! Będziesz mieć możliwość poprawiania naszych błędów stylistycznych, ortograficznych czy gramatycznych. Przez to tłumaczenia staną się łatwiejsze w odbiorze dla reszty użytkowników. Oprócz tego będziesz mieć dostęp do najnowszych tłumaczeń wcześniej niż użytkownicy nie biorący udziału w projekcie.
Nic nie szkodzi!
Dokument, który czytasz wyjaśnia jak możesz z nami współpracować, zarówno używając systemu Linux, jak i Windows. Możesz korzystać z dowolnego systemu operacyjnego. Nie ma ku temu żadnych przeciwskazań.
Przyłącz się! W dalszych rozdziałach dowiesz się więcej o tym jakiego oprogramowania będziesz potrzebować oraz jak je skonfigurować.
Dochodzimy do sedna sprawy. Po to właśnie powstał ten dokument. Ma on za zadanie wyjaśnić wszelkie kwestie związane z udziałem w projekcie. Kolejne rozdziały opisują listę dyskusyjną, archiwum, system CVS, format DebianDoc, sposób tłumaczenia stron WWW, szablonów oraz ogólne zasady dotyczące tłumaczeń i narzędzia wspomagające.
Życzę przyjemnej lektury i mam nadzieję, że gdy ją zakończysz, bez problemu
staniesz się członkiem PDDP!
Ogólnie rzecz ujmując jest to system rozsyłania wiadomości poprzez pocztę elektroniczną. Zasada działania listy dyskusyjnej jest bardzo prosta. Ludzie chcący z niej korzystać muszą wyrazić na to zgodę. Rejestrują się w bazie, podając swój adres poczty elektronicznej. Operacja ta zwana jest również subskrypcją. Oprócz tego na potrzeby funkcjonowania listy tworzony jest specjalny adres poczty. Każda wiadomość wysłana na ten adres jest automatycznie rozsyłana do skrzynek pocztowych wszystkich, którzy są na liście zapisani.
Tak już ten świat jest zorganizowany, że aby współpracować trzeba się jakoś porozumiewać. Jako, że w przypadku komunikacji za pośrednictwem Internetu mowa nie jest najlepszym sposobem, stosujemy listę dyskusyjną. To na niej odbywają się wszelkie dyskusje oraz ustalenia dotyczące tłumaczeń i funkcjonowania grupy.
By uczestniczyć w projekcie trzeba zapisać się na listę!
Zapisując się wyrażasz zgodę na archiwizację i publikację swoich wypowiedzi! Więcej dowiesz się w części dotyczącej archiwum.
Interfejs do obsługi listy dyskusyjnej jest dostępny pod adresem http://debian.linux.org.pl/mailman/listinfo/pddp.
Aby się zapisać (dokonać subskrypcji) należy wypełnić formularz, który wygląda
mniej więcej tak :
Your email address: [ ]
Pick a password: [ ]
Reenter password to confirm: [ ]
[ SUBSCRIBE ]
W pierwszym okienku należy wprowadzić swój adres poczty elektronicznej. W drugim i trzecim proponowane hasło. Konieczność wprowadzania hasła dwukrotnie jest spowodowana troską o brak pomyłek (literówek). Trudniej dwa razy popełnić ten sam błąd.
Uwaga: Nie należy stosować "cennych" haseł. To znaczy takich, którymi mamy zabezpieczone również inne skrzynki pocztowe czy konta na domowym komputerze. Dlatego, że hasło przesyłane jest w postaci czystego tekstu w liście elektronicznym, który powinieneś niebawem otrzymać. W takiej formie jest łatwym celem ataków ludzi do tego nieuprawionych. Ostrzeżono Cię.
Wypełniony formularz mógłby wyglądać na przykład tak :
Your email address: [fenio@debian.org ]
Pick a password: [****** ]
Reenter password to confirm: [****** ]
[ SUBSCRIBE ]
Zauważ: Hasło będzie widoczne w postaci gwiazdek!
Formularz zatwierdzamy przyciskiem SUBSCRIBE.
W tym momencie powinna pokazać się strona z informacją, że na podany adres poczty został wysłany list z prośbą o potwierdzenie rejestracji. Jeśli pojawiło się coś innego, to znaczy, że gdzieś był błąd. Wróć i spróbuj ponownie.
Jeśli wszystko wypełniono prawidłowo, w Twojej skrzynce pocztowej powinna pojawić się nowa wiadomość. Jej nadawcą jest pddp-request@debian.linux.org.pl. Oto przykładowy temat wiadomości :
pddp -- confirmation of subscription -- request 123456
W treści są informacje o tym, że żeby dokończyć procedurę rejestracji należy wysłać na adres pddp-request@debian.linux.org.pl list z numerem subskrypcji w temacie, lub w treści wiadomości. System został, jednakże tak zaprojektowany, że w większości klientów pocztowych wystarczy skorzystać z funkcji "Odpowiedz", a potem nie zmieniając nic w wiadomości, z funkcji "Wyślij". Jeśli klient pocztowy nie dokona żadnych nieprzewidzianych zmian, to taka wiadomość wystarczy do potwierdzenia subskrypcji.
Jeżeli wszystko pójdzie po naszej myśli to w Twojej skrzynce pojawi się kolejna wiadomość. Tym razem potwierdzająca rejestrację. Jej temat powinien wyglądać tak :
Welcome to the "pddp" mailing list
Jeśli masz w swojej skrzynce taką wiadomość, to znaczy, że procedura rejestracji powiodła się i od tej pory będziesz otrzymywać kopie wszystkich wiadomości publikowanych na liście.
Wiadomości rozsyłane przez listę są tak zmodyfikowane, że wystarczy użyć funkcji "Odpowiedz" w swoim kliencie pocztowym, by móc włączyć się do dyskusji. Automatycznie zostaną ustawione wszystkie niezbędne nagłówki wysyłanej wiadomości. Pozostaje tylko dopisać coś od siebie i skorzystać z funkcji "Wyślij". Twoja wiadomość zostanie rozesłana do wszystkich subskrybentów.
Jest tylko jedno, aczkolwiek bardzo ważne "ale". Należy stosować się do zasad tak zwanej netykiety, które postaram się przedstawić w następnym podrozdziale.
Swoje komentarze/przemyślenia należy bezwzględnie umieszczać pod cytowanymi wypowiedziami. Dla zobrazowania tej zasady posłużę się przykładem. Załóżmy, że ktoś napisał w liście:
Ładna jest dzisiaj pogoda!
Odpowiadając na taki list i zakładając, że chcesz dopisać "U mnie też..." należy sformatować wiadomość w taki sposób by przypominała poniższy przykład:
Użytkownik xxx w wiadomości napisał:
> Ładna jest dzisiaj pogoda!
U mnie też...
Niedopuszczalne jest natomiast, by odpowiedź wyglądała w ten sposób:
U mnie też...
Użytkownik xxx w wiadomości napisał:
> Ładna jest dzisiaj pogoda!
Różnicę widać gołym okiem i mam nadzieję, że nie wymaga to dalszych komentarzy. Oczywiście linia zawierająca "Użytkownik xxx w wiadomości napisał:" jest automatycznie generowana przez program pocztowy.
Odpowiadając na czyjąś wiadomość zostawiamy jedynie te fragmenty, do których się bezpośrednio odnosimy. Nie należy generować zbędnego ruchu poprzez zamieszczanie całej cytowanej wiadomości poprzednika.
Nie usuwamy natomiast całości cytatów. Wtedy nie wiadomo do czego odnosi się nasz komentarz.
Należy znaleźć tak zwany "złoty środek" i zostawiać tyle cytatów ile potrzebne jest na to by na podstawie tej wiadomości móc zorientować się o co chodzi.
Sygnaturkę (podpis) osoby na której list odpowiadamy należy bezwzględnie usunąć. Wyjątek stanowi komentarz odnośnie sygnaturki, ale jest to margines.
Należy tak skonfigurować swojego klienta pocztowego by maksymalna długość linii nie przekraczała 78 znaków. Trzeba wziąć pod uwagę, że nie wszyscy używają programów w trybie graficznym, a konsola wprowadza pewne ograniczenia.
Należy tak skonfigurować swojego klienta pocztowego by wiadomości wysyłane były w formacie "plain text" (czysty tekst). HTML zostawiamy dla potrzeb stron WWW. Tę informację kieruję głównie do użytkowników programu MS Outlook Express, gdyż tam domyślnie ustawione jest by wiadomości wysyłane były w formacie HTML. Należy to zmienić.
Na liście obowiązuje ograniczenie maksymalnego rozmiaru wiadomości, którą można
wysłać. Wynosi ono 20kB. Większe będą odrzucane. Jeśli mamy jakieś większe
pliki, które chcemy pokazać całej grupie należy albo umieścić je najpierw na
jakiejś stronie WWW, a w wiadomości podać do niej odsyłacz, albo przesłać te
pliki do koordynatora projektu, a on już to zrobi. Adres koordynatora to
fenio@debian.org
Wysyłając wiadomość trzeba mieć na względzie, że im jest ona dłuższa tym bardziej nużąca i nudząca czytelnika. Staramy się więc pisać na tyle krótko na ile to możliwe by zachować sens wypowiedzi.
Lista służy do komunikacji grupy ludzi zajmującej się tłumaczeniem dokumentacji. W związku z tym wiadomość o tym, że Twoje ziemniaki w piwnicy zaczynają gnić, będzie co najmniej nie na miejscu. Mimo, iż część osób może znać rozwiązanie Twojego problemu, i zalecać sprzedanie tych ziemniaków na frytki do baru u McDonalda. Takie rozmowy należy prowadzić na listach dotyczących przetwarzania produktów rolnych. Na naszej liście piszemy tylko na tematy związane z działalnością grupy.
Ewentualne rozmowy nie dotyczące ściśle tematyki grupy należy prowadzić umieszczając w temacie listu ciąg [OT] tak by ludzie nie chcący tego czytać mogli takie wiadomości filtrować.
Nic tak nie poprawia wiarygodności autora wiadomości jak umieszczenie swojego imienia i nazwiska. Listy niepodpisane, lub podpisane jakimiś pseudonimami nie wzbudzają należytego szacunku. Należy tak skonfigurować klienta poczty by te dane były łatwo widoczne. Bądź w nagłówku From: (Od:), bądź w sygnaturce.
Przyjęło się, że sygnaturka (podpis pod listem) nie powinna przekraczać 4 linii. Przestrzegamy tej zasady.
Większość klientów pocztowych potrafi na podstawie specjalnej sekwencji znaków
automatycznie usuwać sygnaturkę osoby na której listy odpowiadamy. Należy więc
stosować takie usprawnienie i oddzielać sygnaturkę od reszty wiadomości tą
sekwencją. Sekwencja, zwana delimetrem, wygląda następująco : "-- "
(dwie kreski i spacja, bo cudzysłowy pomijamy). Należy stosować właśnie taką
sekwencję albo nie używać podpisu wcale. Ta część jest kierowana głównie do
użytkowników oprogramowania firmy Microsoft, gdyż to jej programy mają problemy
z odpowiednią obsługą tej sekwencji. By dostosować program Outlook Express z
pewnością pomocna będzie strona http://www.oe.it-faq.pl.
Zastosowanie porad tam zawartych pozwoli uniknąć wielu nieporozumień na liście.
Nie piszemy DUŻYMI LITERAMI. Taki styl pisania odbierany jest jako krzyk. Jeśli koniecznie chcemy podkreślić/uwydatnić znaczenie jakiegoś wyrazu należy umieścić go pomiędzy znakami "*". Na przykład tak: *ważne*.
List napisany starannie, stylistycznie oraz zgodnie z zasadami ortografii i gramatyki polskiej na pewno zwróci większą uwagę czytelników, niż niechlujne i naprędce napisane bazgroły.
Wyłączamy numerowanie odpowiedzi w tematach. Niedopuszczalne jest by pojawiały się dziwolągi w stylu Re[5]: Temat. Ta uwaga jest kierowana głównie do użytkowników programu pocztowego The Bat! gdyż on domyślnie ma ustawione takie numerowanie. Należy w szablonie odpowiedzi umieścić wpis %singlere.
Stosujemy pojedyncze znaki cytowania. Najlepiej używać po prostu najpowszechniejszego znaku >. Nie używamy natomiast do cytowania inicjałów poprzednika. Wynalazki typu BF> cytat są zabronione.
Aby rozpocząć zupełnie nowy wątek dyskusji należy wysłać wiadomość na adres
pddp@debian.linux.org.pl.
Taka wiadomość automatycznie zostanie rozesłana do wszystkich zasubskrybowanych
użytkowników (w tym również do Ciebie).
Każda wiadomość pojawiająca się na liście jest automatycznie archiwizowana.
Całość archiwum można przeglądać pod adresem http://archiwum.debian.linux.org.pl.
Dostęp do archiwum mają tylko uczestnicy projektu. Hasło jest takie samo jak
to, które posiadasz by korzystać z repozytorium. Wysyłając wiadomość wyrażamy
zgodę na jej publikację, a tym samym należy dbać o to by jej treść nie
naruszała czyjejś godności osobistej.
Aby wypisać się z listy, zmienić opcje subskrypcji lub odzyskać swoje hasło
należy skorzystać z panelu konfiguracyjnego. W tym celu trzeba udać się na
stronę http://debian.linux.org.pl/mailman/listinfo/pddp.
Na samym dole tej strony pod napisem "To change your subscription..."
znajduje się okienko w które należy wprowadzić swój adres poczty
elektronicznej. Następnie naciskamy przycisk "Edit Options".
Naszym oczom powinna ukazać się strona z wieloma różnymi przełącznikami i formularzami.
W części "Unsubscribing from pddp" w okienku wprowadzamy swoje hasło, a następnie naciskamy przycisk "Unsubscribe".
Od tej chwili wiadomości z listy przestaną do Ciebie przychodzić.
System jest tak skonstruowany, że hasło można odzyskać bardzo łatwo. W części nazwanej "Forgotten Your Password?" znajduje się przycisk o nazwie "Email My Password To Me". Należy go kliknąć.
W Twojej skrzynce powinna pojawić się wiadomość z tematem "pddp@debian.linux.org.pl mailing list reminder". W treści wiadomości będzie hasło.
Oprócz głównej listy dyskusyjnej posiadamy jeszcze drugą listę, na której publikowane są wiadomości o przesyłaniu poprawek do repozytorium. Ta lista ma status "tylko do odczytu" co oznacza, że nie można na nią wysyłać wiadomości. Może to robić tylko skrypt informujący o przesyłaniu plików do CVS. Subskrypcja nie jest obowiązkowa, ale jest zalecana.
Aby zapisać się na tę listę należy wykonać te same kroki co w przypadku głównej
listy. Interfejs do jej obsługi znajduje się pod adresem http://debian.linux.org.pl/mailman/listinfo/cvs.
Informacja o przesłaniu poprawek może wyglądać tak:
fenio Mon, 30 Jun 2003 16:36:02 +0200
Pliki zmodyfikowane:
manuals.sgml/quick-reference/pl:
system.sgml
Opis:
trochę korekty
Wersja Zmiany Ścieżka
1.10 +46 -45 manuals.sgml/quick-reference/pl/system.sgml
Odsyłacz do ViewCVS:
http://debian.linux.org.pl/cgi-bin/viewcvs.cgi/manuals.sgml/quick-reference/pl/system.sgml.diff?r1=text&tr1=1.9&r2=text&tr2=1.10&diff_format=h
Jak widać oprócz takich informacji jak nazwa i wersja zmodyfikowanych plików, dostępny jest również komentarz, dane na temat ilości zmienionych linii oraz odsyłacz do ViewCVS, który pozwala łatwo przenieść się na stronę gdzie wyświetlone będą wszelkie zmiany.
To wszystko co musisz wiedzieć o korzystaniu z listy dyskusyjnej. Postaraj się jednak najpierw przez jakiś czas pośledzić zwyczaje na niej panujące. Nie zaczynaj od wysyłania wiadomości, bo jest duże prawdopodobieństwo, że zrobisz coś nie tak jak jest to ogólnie przyjęte. Jednakże stosowanie się do powyższej netykiety powinno zapewnić Ci bezproblemowe branie udziału w naszych dyskusjach.
Bardzo proszę o dokonywanie subskrypcji z adresów, które nie mają tendencji do nagłego znikania czy przepełnienia wolnego miejsca. Zastrzegam sobie prawo do usunięcia takich subskrypcji. Tak więc jeśli ktoś postawił sobie serwer na SDI i subskrybuje listę z adresu ktoś@jakieś.sdi.tpnet.pl i zamierza nagle wyłączyć komputer, bo jedzie na wakacje to niech liczy się z tym, że subskrypcja zostanie anulowana.
Concurrent Versions System (w skrócie CVS) jest narzędziem wspomagającym grupową pracę nad danymi komputerowymi, w szczególności plikami tekstowymi. Jest powszechnie stosowany w projektach OpenSource.
Żeby grupa ludzi mogła wspólnie pracować nad jakimś projektem w tradycyjny sposób, istniałaby potrzeba przesyłania wprowadzonych przez każdą osobę zmian, do jednej wybranej osoby, która miałaby za zadanie "sklejać" to wszystko w całość. Nietrudno wyobrazić sobie jak bardzo czasochłonną i żmudną byłoby to czynnością. Dlatego też powstał ten system. Ma za zadanie to usprawnić i zautomatyzować.
Wszystkie pliki projektu trzymane są w jednym miejscu, w tak zwanym repozytorium. Każdy pobiera sobie te pliki na swój dysk, a następnie po wprowadzeniu poprawek odsyła je. Wiele osób może w tym samym czasie pracować nad jednym plikiem, a po przesłaniu ich z powrotem system CVS zajmie się łączeniem wszelkich naniesionych zmian w jeden plik wynikowy. Kolejną zaletą tego systemu jest pamiętanie poprzednich wersji. Nic więc nie stoi na przeszkodzie by w każdej chwili cofnąć wprowadzone zmiany. Pozwala to kontrolować jakość i poprawność zmian oraz ewentualnie przywracać stan sprzed ich wprowadzenia w przypadku błędów.
Jest bardzo zalecane, aby każdy z członków grupy umiał i korzystał z CVS.
Aby móc korzystać z systemu CVS musisz posiadać w nim konto. Dzięki temu nikt niepowołany nie może modyfikować naszych zbiorów.
Jak zdobyć konto?
Konta w naszym systemie CVS zakłada koordynator. Należy do niego przesłać list zawierający proponowaną nazwę konta oraz hasło. Najlepiej, by hasło było przesyłane w postaci zaszyfrowanej. By zaszyfrować hasło, można użyć polecenia:
perl -e 'printf(crypt("aaaaaaaa","bb")."\n")'
Ciąg znaków aaaaaaaa należy zastąpić proponowanym hasłem, a bb dowolnymi dwoma literami lub cyframi. Przykładowy przebieg szyfrowania prezentuję poniżej:
(fenio@domek)~$perl -e 'printf(crypt("rowerek","55")."\n")'
5539KZmftZRaU
(fenio@domek)~$
To, co zwróci nam polecenie Perla, to właśnie zaszyfrowane hasło, które należy przesłać do koordynatora. W tym wypadku jest to ciąg znaków 5539KZmftZRaU. Tak właśnie wygląda zaszyfrowane słowo rowerek.
Uprzedzam przed zbytnio skomplikowanymi hasłami. Zdarza się czasem, że pomimo poprawnie zaszyfrowanego hasła - ono nie działa. Nie wiem czemu tak się dzieje, ale podejrzewam, że funkcja szyfrująca nie lubi się z ,,dziwnymi'' znaczkami. Dlatego zalecam unikać haseł typu HmnQ;/qrv,as a w zamian stosować jakieś prostsze typu fragles12 czy s4setka. Pozwoli to zaoszczędzić niepotrzebnych problemów.
Jeśli nie posiadasz dostępu do programu Perl, nie przejmuj się.
Możesz również przesłać niezaszyfrowane hasło. Jedyna różnica to fakt, iż
będzie je znał koordynator, ale jest to osoba raczej godna zaufania ;)
Zaszyfrowane hasła składają się z 13 znaków. Sprawdź czy Twoje również ma tyle.
Mając wybrany login (nazwę konta) oraz hasło, należy je przesłać na adres
fenio@debian.org. W
opisanym powyżej przypadku treść wiadomości mogłaby wyglądać następująco:
Proszę o założenie konta w CVS. Oto proponowane dane:
login: fenio
hasło: 5539KZmftZRaU
Tak przygotowany list wysyłamy. Po jakimś czasie spodziewać się można wiadomości zwrotnej z informacją o założeniu (bądź nie) konta. Może się zdarzyć, że dana nazwa konta jest już wykorzystana, wtedy koordynator o tym poinformuje i będzie trzeba wybrać nazwę ponownie oraz powtórzyć procedurę.
Uwaga: W żadnym wypadku nie należy przesyłać hasła na adres listy dyskusyjnej.
Dalsze postępowanie zależy od tego jakiego systemu operacyjnego, a co za tym idzie oprogramowania, używasz. Dlatego też, ten podrozdział został podzielony na dwie części. Pierwsza z nich opisuje sposób korzystania z CVS pod systemem Linux, a druga pod systemem Windows. Opuść podrozdział, który Cię nie dotyczy.
Zakładam, iż używasz dystrybucji Debian GNU/Linux. W końcu bierzesz udział w projekcie tłumaczącym dokumentację do tej właśnie dystrybucji. Część poleceń może nie zadziałać w innych dystrybucjach, szczególnie te, dotyczące instalacji oprogramowania.
Będziemy potrzebować programu umożliwiającego korzystanie z CVS. Do instalacji
oprogramowania posłużymy się narzędziem apt-get. Będąc
zalogowanym jako administrator (root), wprowadź w linii poleceń:
apt-get install cvs
Możliwe, że masz już zainstalowane odpowiednie pakiety. Wtedy na ekranie ujrzysz:
(root@domek)~$apt-get install cvs
Reading Package Lists... Done
Building Dependency Tree... Done
Sorry, cvs is already the newest version.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(root@domek)~$
W takim przypadku resztę tego podrozdziału możesz opuścić. W przeciwnym wypadku zastosuj się do poniższych wskazówek.
Po chwili, potrzebnej na pobranie pakietu z sieci i jego rozpakowaniu, powinno pojawić się okno konfiguracyjne.
Debconf zapyta Cię gdzie umieszczone są Twoje repozytoria.
Obojętne co odpowiesz na to pytanie, gdyż ta opcja jest wykorzystywana tylko w
przypadku udostępniania, a Ty jedynie będziesz korzystać z innego repozytorium.
Najbezpieczniej po prostu wcisnąć w tym miejscu [ENTER].
Następne pytanie dotyczy obsługi mechanizmu pserver. Sytuacja jest podobna do powyższej. Funkcja ta ma znaczenie przy tworzeniu repozytorium, więc Ciebie nie dotyczy. Znowu naciskamy [ENTER], a przy pytaniu "Should the CVS pserver be enabled?" odpowiadamy [NO]. To wszystko. Potrzebne oprogramowanie jest zainstalowane.
Pierwszą czynnością jaką musimy wykonać to pobranie plików z głównego
repozytorium. Przedtem jednak lepiej utworzyć na to specjalny katalog (na
przykład pddp). By tego dokonać wprowadź mkdir pddp.
Następnie przejdź do tego katalogu (cd pddp). By się zalogować w
systemie CVS będziesz potrzebować nazwy konta oraz hasła. Wprowadź następujące
polecenie:
cvs -d :pserver:nazwa_konta@debian.linux.org.pl:/home/cvs login
Oczywiście zmień nazwa_konta na nazwę zatwierdzoną przez koordynatora. Następnie CVS poprosi o podanie hasła. Wprowadź je (w formie niezaszyfrowanej) i naciśnij [ENTER]. Jeśli wszystko pójdzie bezbłędnie, nie powinny pokazać się żadne komunikaty, a jedynie znowu znak zachęty powłoki. Oto przykład jak prawidłowo powinno wyglądać logowanie:
(fenio@domek)~/pddp$cvs -d :pserver:fenio@debian.linux.org.pl:/home/cvs login
Logging in to :pserver:fenio@debian.linux.org.pl:2401/home/cvs
CVS password:
(fenio@domek)~/pddp$
W przykładzie nazwą konta jest fenio. Należy zastąpić ją swoją nazwą. Teraz pobierzmy pliki. Zważ na to, że całe repozytorium to ponad 50MB! Będąc w tym samym katalogu wprowadź polecenie:
cvs -d :pserver:nazwa_konta@debian.linux.org.pl:/home/cvs checkout ./
Zamień nazwa_konta na swoją nazwę tak jak w poprzednim poleceniu. Poniżej przykład jak może wyglądać efekt tego polecenia:
(fenio@domek)~/pddp$cvs -d :pserver:fenio@debian.linux.org.pl:/home/cvs checkout ./
cvs server: Updating .
cvs server: Updating CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg
cvs server: Updating pddp
U pddp/slownik.txt
U pddp/zasady.txt
cvs server: Updating pddp/pomoc
U pddp/pomoc/cvs.sgml
U pddp/pomoc/generuj
U pddp/pomoc/lista.sgml
U pddp/pomoc/pomoc.sgml
U pddp/pomoc/wstep.sgml
cvs server: Updating pddp/skrypty
U pddp/skrypty/generuj
U pddp/skrypty/pddp_check.pl
U pddp/skrypty/slownik
(fenio@domek)~/pddp$
Lista pobranych plików z pewnością będzie dłuższa (w momencie pisania tych słów
- wrzesień 2004 - repozytorium zajmuje ponad 120MB). Dla zobrazowania zasady
działania wystarczy nam jednak wycinek tej listy. W tym momencie w katalogu
~/pddp utworzonych zostało kilka podkatalogów
(CVSROOT, pddp itd.). W nich znajdują się różne
pliki, począwszy od dokumentów, które tłumaczymy, poprzez różnego rodzaju
skrypty wspomagające naszą pracę, na słowniku projektu kończąc. Reasumując
stworzyliśmy lokalną kopię repozytorium.
Polecenie cvs można jeszcze wzbogacić o opcję -zx, gdzie x to dowolna cyfra. Opcja ta ustala stopień kompresji podczas przesyłania plików. 1 oznacza najsłabszą, ale zarazem najszybszą kompresję, a 9 najsilniejszą, ale najbardziej czasochłonną. Cyfry pomiędzy 1 a 9, ustalają odpowiednio coraz większy stopień kompresji. Tak wyglądałoby polecenie z 6 stopniem kompresji:
cvs -z6 -d :pserver:fenio@debian.linux.org.pl:/home/cvs checkout ./
W powyższym przykładzie po opcji checkout umieściłem ./, co oznacza główny katalog repozytorium. Częściej stosowane są jednak nazwy konkretnych katalogów. Polecenie mogłoby wyglądać na przykład tak:
cvs -d :pserver:fenio@debian.linux.org.pl:/home/cvs checkout pddp
Wtedy pobrany zostałby tylko jeden katalog o nazwie pddp. Główne
katalogi repozytorium zwane są również modułami. Jednakże dla potrzeb naszego
projektu najlepiej pobrać wszystkie katalogi, tak jak zostało to pokazane.
Przed przystąpieniem do edycji jakiegoś pliku zawsze należy wykonać aktualizację lokalnej kopii.
Zakładam, że nadal jesteś w katalogu ~/pddp. By zaktualizować
lokalną kopię repozytorium wystarczy wprowadzić polecenie:
cvs update.
Więcej szczegółów i przykład jak może wyglądać wynik takiego polecenia, znajduje się w dalszej części tego rozdziału. Na razie wystarczy Ci jedynie znajomość tego polecenia.
Po zmodyfikowaniu jakiegoś pliku, należy przesłać poprawki z powrotem do
repozytorium. Zakładam, że nadal znajdujesz się w głównym katalogu swojej
lokalnej kopii repozytorium, czyli postępując według moich wskazówek, bieżącym
katalogiem powinien być ~/pddp.
Przesłania pliku do głównego repozytorium można dokonać na dwa sposoby.
Wprowadź następujące polecenie:
cvs commit -m "opis wprowadzonych zmian" ścieżka/plik
Załóżmy, że zmodyfikowany plik to cvs.sgml znajdujący się w
podkatalogu pddp/pomoc/. To przykład zastosowania takiego
polecenia. Jest on z życia wzięty (ten dokument powstaje właśnie w
repozytorium CVS).
(fenio@domek)~/pddp$cvs commit -m "opis przesyłanych zmian" pddp/pomoc/cvs.sgml
Checking in pddp/pomoc/cvs.sgml;
/home/cvs/pddp/pomoc/cvs.sgml,v <-- cvs.sgml
new revision: 1.6; previous revision: 1.5
done
(fenio@domek)~/pddp$
System poinformował nas, że przesłał plik do repozytorium oraz, że po nałożeniu naszych zmian przyporządkował plikowi nowy, kolejny numer wersji (w tym przypadku 1.6). Oczywiście jeśli znajdujemy się w tym samym katalogu co plik, który chcemy przesłać, to ścieżkę dostępu można pominąć.
Wprowadź następujące polecenie:
cvs commit
Przy takim poleceniu CVS sam przeszuka lokalną kopię repozytorium w
poszukiwaniu zmodyfikowanych plików. Oto kolejny przykład z życia wzięty. Po
modyfikacji pliku cvs.sgml przesyłam poprawki innym sposobem.
Wynik powyższego polecenia może wyglądać tak:
(fenio@domek)~/pddp$cvs commit
cvs commit: Examining .
cvs commit: Examining CVSROOT
cvs commit: Examining pddp
cvs commit: Examining pddp/pomoc
cvs commit: Examining pddp/skrypty
cvs commit: Examining verbose
cvs commit: Examining verbose/debian_install
cvs commit: Examining verbose/debian_kernel
[ ..:: CZĘŚĆ INTERAKTYWNA ::.. ]
Checking in pddp/pomoc/cvs.sgml;
/home/cvs/pddp/pomoc/cvs.sgml,v <-- cvs.sgml
new revision: 1.7; previous revision: 1.6
done
(fenio@domek)~/pddp$
Widać, że zmiany zostały przesłane, a CVS znowu zwiększył numer wersji tego pliku (teraz wynosi 1.7). No tak, ale ktoś mógłby spytać gdzie tu ta cała interaktywność lub gdzie wprowadzić opis dokonanych zmian. Otóż podczas wykonywania tego polecenia, w miejscu oznaczonym przeze mnie w powyższym przykładzie jako [ ..:: CZĘŚĆ INTERAKTYWNA ::.. ] zostaje uruchomiony edytor tekstu z taką zawartością:
CVS: ----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: pddp/pomoc/cvs.sgml
CVS: ----------------------------------------------------------------------
Program informuje nas jakie pliki zostały zmienione. Prosi również o wprowadzenie komentarza opisującego dokonane zmiany. Należy tego dokonać w pierwszej, pustej linii. Reszta linii, rozpoczynających się od CVS: zostanie usunięta przed przesłaniem automatycznie, o czym również jesteśmy informowani. Tak może wyglądać zawartość tuż przed przesłaniem:
opis przesyłania plików interaktywnie
CVS: ----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: pddp/pomoc/cvs.sgml
CVS: ----------------------------------------------------------------------
Jak widać zmieniła się tylko pierwsza linia. Pojawił się komentarz. Jeśli uważamy, że wszystko jest gotowe do przesłania, to należy wyjść z edytora, zapisując zmiany.
Należy tutaj jeszcze wspomnieć coś więcej o edytorze. Skąd CVS wie jakiego
edytora użyć do wprowadzenia komentarza? Tę informację pobiera ze zmiennej
środowiskowej $EDITOR lub $CVSEDITOR. Najpierw sprawdza zmienną $CVSEDITOR, a
jeśli jest pusta to sprawdza zmienną $EDITOR. Domyślnie zmienna $CVSEDITOR nie
jest ustawiona w systemie, a zmienna $EDITOR najczęściej wskazuje na edytor
vi lub vim. I taki też edytor zostanie uruchomiony.
Nie wszystkim musi to odpowiadać, a wtedy należy zmienić zawartość
którejkolwiek ze zmiennych.
Dokonuje się tego poleceniem export ZMIENNA=/sciezka/do/edytora. Jednakże po wylogowaniu się i ponownym zalogowaniu zmienna tak ustawiona będzie miała z powrotem starą wartość. Aby ustawić tę zmienną na stałe trzeba powyższe polecenie umieścić w jednym z plików konfiguracyjnych, które są przetwarzane podczas logowania.
Oto przykładowe polecenie, które sprawi, że zmienna $EDITOR będzie po zalogowaniu wskazywała na edytor z programu Midnight Commander (/usr/bin/mcedit):
echo "export EDITOR=/usr/bin/mcedit" >> ~/.bash_profile
W przykładzie zakładam, że używasz powłoki Bash, ponieważ taka jest standardowo ustawiana w systemie Debian. Jeśli używasz innej to zapewne poradzisz sobie z samodzielnym ustawieniem odpowiedniej zmiennej.
Może się zdarzyć, że podczas gdy my nanosiliśmy poprawki na jakiś plik, w tym samym momencie robił to ktoś inny. Co więcej, załóżmy, że ta druga osoba przesłała już swoje zmiany do repozytorium. Co to oznacza?
Jak łatwo się domyśleć teraz nasze poprawki nie odnoszą się już do najnowszej wersji dokumentu. Co się stanie gdy spróbujemy przesłać nasze poprawki do repozytorium?
Załóżmy, że wcześniej pobraliśmy z repozytorium plik cvs.sgml w
wersji 1.17. Dokonaliśmy własnych poprawek i teraz chcemy je przesłać.
Zgodnie z wcześniejszym podrozdziałem wprowadzamy:
cvs commit -m "opis zmiany" pddp/pomoc/cvs.sgml
Oto efekt takiego polecenia:
(fenio@domek)~/pddp$cvs commit -m "konflikty" pddp/pomoc/cvs.sgml
cvs server: Up-to-date check failed for `pddp/pomoc/cvs.sgml'
cvs [server aborted]: correct above errors first!
(fenio@domek)~/pddp$
Jak widać przesłanie nie powiodło się. CVS poinformował nas, że nasze modyfikacje nie odnoszą się do najświeższej wersji z repozytorium. Prosi o poprawienie tego. Sposób poprawienia zależy jednak od tego czy nasze zmiany znajdują się w tej samej części pliku czy nie. Poniżej opisuję obie sytuacje:
W takim przypadku system CVS powinien poradzić sobie z połączeniem naszych zmian ze zmianami poprzednika i utworzeniem jednego pliku wynikowego. By to zrobić wprowadź polecenie:
cvs update
Tak może to wyglądać w rzeczywistości:
(fenio@domek)~/pddp$cvs update
cvs server: Updating .
cvs server: Updating CVSROOT
cvs server: Updating pddp
cvs server: Updating pddp/pomoc
RCS file: /home/cvs/pddp/pomoc/cvs.sgml,v
retrieving revision 1.17
retrieving revision 1.18
Merging differences between 1.17 and 1.18 into cvs.sgml
M pddp/pomoc/cvs.sgml
cvs server: Updating pddp/skrypty
cvs server: Updating verbose
cvs server: Updating verbose/debian_install
cvs server: Updating verbose/debian_kernel
(fenio@domek)~/pddp$
CVS przegląda całą lokalną kopię repozytorium i porównuje ją z główną kopią
znajdującą się na serwerze. Pobiera informacje o zmianach w pliku
cvs.sgml i stara się połączyć je z naszą zmienioną wersją.
Informuje o tym w linii "Merging...". Operacja zakończyła się
sukcesem. Dodatkowo CVS zapisuje ukryty plik oryginału sprzed połączenia
zmian. W naszym przypadku plik ten otrzymał nazwę
.#cvs.sgml.1.17, więc jak widać w nazwie jest zapisana wersja.
Plik ten jest zapisywany na wypadek, gdybyśmy chcieli sami sprawdzić czy CVS
poprawnie połączył zmiany. Jeśli nie chcemy tego robić można usunąć ten plik
poleceniem rm -f .#cvs.sgml.1.17. Teraz pozostaje nam przesłanie
pliku z połączonymi zmianami do repozytorium. Robimy to dokładnie tak jak
przedtem wpisując:
cvs commit -m "opis zmiany" pddp/pomoc/cvs.sgml
A oto wynik takiego polecenia:
(fenio@domek)~/pddp$cvs commit -m "poprawiony konflikt"
pddp/pomoc/cvs.sgml
Checking in pddp/pomoc/cvs.sgml;
/home/cvs/pddp/pomoc/cvs.sgml,v <-- cvs.sgml
new revision: 1.19; previous revision: 1.18
done
(fenio@domek)~/pddp$
Tym razem nasze poprawki zostały przesłane i naniesione bez przeszkód.
Tutaj sytuacja trochę się komplikuje. Program komputerowy choćby nie wiem jak sprawnie napisany pozostanie programem. Nie posiada inteligencji i sam nie jest w stanie stwierdzić, które poprawki są prawidłowe. Czy te wprowadzone przez nas czy przez poprzednią osobę.
Aby przedstawić zasadę rozwiązywania problemów przy nakładających się na siebie zmianach posłużę się specjalnym przykładowym zdaniem, które będzie znajdować się w tym pliku i które będziemy modyfikować. Będzie to jedna linijka tak by łatwo można było wytłumaczyć na czym polega rozwiązywanie takich konfliktów. Oto nasze zdanie:
Ala ma kota.
Załóżmy, że pobraliśmy plik z repozytorium w wersji 1.23. Teraz stwierdziliśmy, że przykładowe zdanie należy zmodyfikować. Według nas ma ono brzmieć:
Ala ma małego kotka.
Ale niestety okazało się, że ktoś inny stwierdził, że to zdanie należy zmienić na:
Ala Kowalska nie ma kota.
Co więcej, przesłał już swoją poprawkę do repozytorium i w tym momencie istnieje tam już wersja 1.24 z jego modyfikacją tego zdania. Ewidentnie mamy tu konflikt.
Co się stanie jak spróbujemy przesłać nasze poprawki ?
Oczywiście zostaną odrzucone z prośbą o aktualizację naszej kopii repozytorium (tak jak w przykładzie gdzie poprawki się nie nakładały). Nieświadomi tego, że zmiany znajdujące się w głównym repozytorium konfliktują z naszymi (bo przecież nie możemy tego wiedzieć), przystępujemy do aktualizacji naszej kopii repozytorium.
Tak wyglądałby wynik takiej aktualizacji:
(fenio@domek)~/pddp$cvs update
cvs server: Updating .
cvs server: Updating CVSROOT
cvs server: Updating pddp
cvs server: Updating pddp/pomoc
RCS file: /home/cvs/pddp/pomoc/cvs.sgml,v
retrieving revision 1.23
retrieving revision 1.24
Merging differences between 1.23 and 1.24 into cvs.sgml
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in pddp/pomoc/cvs.sgml
C pddp/pomoc/cvs.sgml
cvs server: Updating pddp/skrypty
cvs server: Updating verbose
cvs server: Updating verbose/debian_install
cvs server: Updating verbose/debian_kernel
(fenio@domek)~/pddp$
Jak widać podczas aktualizacji mamy ostrzeżenie o konflikcie. Świadczy o tym linia:
rcsmerge: warning: conflicts during merge
Dodatkowo zostaje utworzony ukryty plik z zawartością sprzed aktualizacji. W
tym przypadku nosi nazwę .#cvs.sgml.1.23. Jego zastosowanie
opisałem w poprzednim podrozdziale.
No dobrze, ale jak rozwiązać problem nakładających się zmian? Zmiany te wbrew pozorom zostały połączone, a jedynie miejsca konfliktowe są specjalnie oznaczone w pliku, który modyfikowaliśmy. W naszym przypadku miejsce konfliktu wygląda tak:
<<<<<<< cvs.sgml
Ala ma małego kotka.
======
Ala Kowalska nie ma kota.
>>>>>>> 1.24
System pokazuje nam obie wersje tego zdania. Zarówno naszą jak i poprzednika. Ty musisz zdecydować, która wersja jest poprawna. Ewentualnie jak połączyć obie wersje w całość, która w tym przypadku mogłaby wyglądać następująco:
Ala Kowalska ma lub nie ma małego kotka.
To jak zostaną połączone zmiany zależy od Ciebie. Gdy się już zdecydujesz, zmodyfikuj oznaczone miejsce. Zostaw tylko jedną wersję zdania i usuń linie zawierające <<<<<<< cvs.sgml, ======= oraz >>>>>>> 1.24. Musisz je usunąć! Inaczej będziesz otrzymywać ostrzeżenia, o nadal istniejących konfliktach.
Teraz możesz przesłać poprawioną wersję z powrotem do repozytorium. Wprowadź poniższe polecenie:
cvs commit -m "poprawka" pddp/pomoc/cvs.sgml
A oto jak wyglądać może jego wynik:
(fenio@domek)~/pddp$cvs commit -m "poprawka" pddp/pomoc/cvs.sgml
Checking in pddp/pomoc/cvs.sgml;
/home/cvs/pddp/pomoc/cvs.sgml,v <-- cvs.sgml
new revision: 1.25; previous revision: 1.24
done
(fenio@domek)~/pddp$
Tym razem nasze poprawki zostały przesłane i naniesione bez przeszkód.
W większości wypadków koordynator troszczy się o dodawanie nowych plików do repozytorium. Może jednak zaistnieć potrzeba zrobienia tego samemu.
Należy to jednak wcześniej oznajmić na liście dyskusyjnej, podając nazwę pliku i miejsce jego lokalizacji. Następnie należy poczekać na komentarz bardziej zaawansowanego użytkownika.
Obostrzenia takie występują ze względu na to, iż CVS prowadzi historię wszelkich operacji. Dodanie pliku jest bardzo proste, ale jego usunięcie już niekoniecznie. Dlatego każda taka modyfikacja powinna być przemyślana i skonsultowana z resztą grupy. A już najlepiej po prostu sygnalizować potrzebę nowego pliku i czekać, aż założy go koordynator lub ktoś bardziej zaawansowany.
Aby jednak instrukcja, którą czytasz była pełniejszym opisem systemu CVS, wypada objaśnić sposób dodawania pliku.
Zakładam, że nadal znajdujesz się w katalogu głównym swojej lokalnej kopii
repozytorium, czyli ~/pddp.
Przyjmijmy, że w katalogu pddp/pomoc/ chcesz utworzyć plik o
nazwie edytor.sgml. Najpierw trzeba utworzyć go w lokalnej kopii
repozytorium. Można to zrobić poleceniem touch
pddp/pomoc/edytor.sgml. O tak założonym pliku należy poinformować
system CVS. Robimy to poleceniem cvs add pddp/pomoc/edytor.sgml.
Oto przykład wykonania takiego polecenia:
(fenio@domek)~/pddp$cvs add pddp/pomoc/edytor.sgml
cvs server: scheduling file `pddp/pomoc/edytor.sgml' for addition
cvs server: use 'cvs commit' to add this file permanently
(fenio@domek)~/pddp$
CVS poinformował nas, że plik ten został umieszczony w kolejce oczekującej na dodanie do głównego repozytorium. W tym momencie plik nie został jeszcze przesłany! W drugiej linii mamy informację, że należy użyć polecenia cvs commit by go przesłać.
Postępujemy więc według tej wskazówki. Ta część wygląda tak samo jak przy przesyłaniu poprawek zmienianych plików. Pamiętamy, że polecenie cvs commit jest interaktywnym sposobem na przesłanie pliku i powoduje uruchomienie się edytora w którym należy wprowadzić informację o przesyłanym pliku. Jeśli chcemy tego dokonać nieinteraktywnie, a ja przedstawię wynik właśnie takiej metody, stosujemy polecenie cvs commit -m "nowy plik" pddp/pomoc/edytor.sgml. Oto wynik takiego polecenia:
(fenio@domek)~/pddp$cvs commit -m "nowy plik" pddp/pomoc/edytor.sgml
RCS file: /home/cvs/pddp/pomoc/edytor.sgml,v
done
Checking in pddp/pomoc/edytor.sgml;
/home/cvs/pddp/pomoc/edytor.sgml,v <-- edytor.sgml
initial revision: 1.1
done
(fenio@domek)~/pddp$
Jak widać, niewiele różni się to od zwykłego przesyłania zmienionych plików. Otrzymujemy jedynie dodatkowe informacje o tym, że jest to pierwsza wersja tego pliku.
To również funkcja z której nie będziesz raczej korzystać. Ale tak jak poprzednio objaśnię ją, dla pełniejszego opisu systemu CVS.
Znowu przyjmuję, że znajdujesz się w katalogu ~/pddp. Załóżmy, że
chcesz usunąć plik, który przed chwilą dodaliśmy, a więc plik o nazwie
edytor.sgml z podkatalogu pddp/pomoc/. Aby to zrobić
musisz najpierw fizycznie usunąć plik, ze swojej lokalnej kopii repozytorium.
Wprowadź polecenie rm -f pddp/pomoc/edytor.sgml. Następnie należy
poinformować o tej zmianie system CVS. Służy do tego polecenie cvs
remove pddp/pomoc/edytor.sgml. Tak może wyglądać wynik tego polecenia:
(fenio@domek)~/pddp$cvs remove pddp/pomoc/edytor.sgml
cvs server: scheduling `pddp/pomoc/edytor.sgml' for removal
cvs server: use 'cvs commit' to remove this file permanently
(fenio@domek)~/pddp$
Tym razem zostaliśmy poinformowani, że plik edytor.sgml został
umieszczony w kolejce do usunięcia. W drugiej linii znowu mamy informację, o
tym, że żeby go całkowicie usunąć z głównego repozytorium należy wprowadzić
polecenie cvs commit. Tak jak wspominałem przy dodawaniu pliku,
jest to interaktywny sposób przesyłania informacji do repozytorium CVS. My
skorzystamy z metody nieinteraktywnej i wprowadzimy polecenie cvs commit
-m "usuwam plik" pddp/pomoc/edytor.sgml. A tak wygląda jego
efekt:
(fenio@domek)~/pddp$cvs commit -m "usuwam plik" pddp/pomoc/edytor.sgml
Removing pddp/pomoc/edytor.sgml;
/home/cvs/pddp/pomoc/edytor.sgml,v <-- edytor.sgml
new revision: delete; previous revision: 1.1
done
(fenio@domek)~/pddp$
Otrzymujemy informację o usunięciu pliku.
Ta możliwość również nie powinna Ci być potrzebna. Takimi rzeczami zajmuje się koordynator. Poza tym CVS nie przewiduje takiej operacji. Należy plik usunąć i dodać ze zmienioną nazwą. Poszczególne czynności są opisane w poprzednich podrozdziałach.
Nawet nie próbuj!
O ile w przypadku plików, pomyłki da się w miarę prosto "odkręcić", to z katalogami wygląda to o wiele gorzej.
Dlatego też w naszym repozytorium obowiązuje bezwzględny zakaz tworzenia katalogów. Potrzebę istnienia jakiegoś katalogu należy zgłosić na liście dyskusyjnej. Zostanie to przedyskutowane i wtedy koordynator założy odpowiedni katalog w dobrze przemyślanej lokalizacji, tak by nie okazało się w przyszłości, że trzeba zmienić jego nazwę lub umiejscowienie.
Jedynie dla celów informacyjnych (a nuż ktoś chce stworzyć własne repozytorium) napiszę, że katalogi dodaje się analogicznie do plików. Usuwanie niestety wymaga ingerencji w "środku" bazy danych całego repozytorium i jest operacją bardzo niezalecaną.
Wystąpił już wcześniej podrozdział o podobnej nazwie. Obiecałem w nim, że później znajdziesz więcej informacji na ten temat. Właśnie nadszedł czas spełnienia obietnicy.
Wiele razy korzystaliśmy z polecenia cvs update, które służy do synchronizacji naszej kopii lokalnej z głównym repozytorium. Teraz bliżej przyjrzymy się temu, co zwraca takie polecenie, a może to wyglądać tak:
(fenio@serwer)~/pddp$cvs update
? pddp/informacja
cvs server: Updating .
cvs server: Updating CVSROOT
cvs server: Updating pddp
cvs server: Updating pddp/pomoc
P pddp/pomoc/cvs.sgml
U pddp/pomoc/edytor.sgml
C pddp/pomoc/wstep.sgml
M pddp/pomoc/pomoc.sgml
cvs server: Updating pddp/skrypty
cvs server: Updating verbose
cvs server: Updating verbose/debian_install
R verbose/debian_install/intro.sgml
cvs server: Updating verbose/debian_kernel
A verbose/debian_kernel/sound.sgml
(fenio@serwer)~/pddp$
Jak widać przy plikach pojawiają się tajemnicze znaki, takie jak ?, P, U, C, M, R oraz A. Warto wiedzieć co one oznaczają, ponieważ są to istotne dla nas informacje.
Znaczenia poszczególnych znaków są następujące:
Jeśli ilość wyświetlanych przez CVS informacji wydaje nam się za duża, można sprawić by program był mniej ,,gadatliwy''. W tym celu należy do poleceń dodawać opcję -q.
I jeszcze jedna dodatkowa informacja. Jeśli do repozytorium zostały dodane jakieś katalogi (z plikami) to zwykłe polecenie cvs update nie ,,zauważy'' ich i tym samym nie pobierze. W takich przypadkach należy wprowadzić polecenie cvs update -d.
Dzięki temu, że CVS trzyma w swojej bazie informacje o każdej wersji pliku, możliwe jest obejrzenie różnic pomiędzy dowolnymi wersjami. Oto przykład polecenia, które to realizuje:
(fenio@domek)~/pddp$cvs diff -r1.16 -r1.15 pddp/pomoc/lista.sgml
Index: pddp/pomoc/lista.sgml
===================================================================
RCS file: /home/cvs/pddp/pomoc/lista.sgml,v
retrieving revision 1.16
retrieving revision 1.15
diff -r1.16 -r1.15
12c12
< rozsyłana do skrzynek pocztowych wszystkich, którzy są na liście zapisani.
---
> rozsyłana na skrzynki pocztowe wszystkich, którzy są na liście zapisani.
(fenio@domek)~/pddp$
Za pomocą polecenia cvs diff wyświetliliśmy różnice pomiędzy
wersjami 1.16 i 1.15 pliku lista.sgml znajdującego się w
podkatalogu pddp/pomoc/. Jak widać wersje podajemy po opcjach
-r. W powyższym przykładzie widać, że pomiędzy tymi wersjami
nastąpiła zmiana jedynie jednego zdania. Najpierw wyświetlony jest tekst,
który znajduje się w wersji 1.16, a później ten z wersji 1.15. Obie wersje
rozdzielone są znakami ---.
Niektóre polecenia cvs posiadają swoje zamienniki lub skróty.
Dzięki temu można zmniejszyć długość wpisywanych poleceń. Na przykład zamiast
wpisywać cvs commit, wystarczy wpisać cvs ci.
Poniżej lista przedstawiająca zamienniki dla poleceń wykorzystanych w tym
dokumencie:
Opisałem tylko część możliwości programu cvs, ale przy pracy w
naszym projekcie wystarczy to w zupełności. Więcej informacji możesz uzyskać w
podręczniku systemowym (man cvs) lub na stronie domowej projektu
CVS, której adres to www.cvshome.org. Koniecznie
przeczytaj informacje ogólne o pracy z systemem CVS znajdujące się w części Informacje dodatkowe.
W następnych podrozdziałach opiszę sposób instalacji oraz korzystania z CVS pod systemem Windows 98 SE Pl, bo tylko taki mam pod ręką. Jeśli posiadasz inną wersję, musisz dokonać odpowiednich korekt samemu.
Będziemy potrzebować programu pozwalającego na korzystanie z systemu CVS.
Najlepszy jaki udało mi się znaleźć to WinCvs. Aktualna, stabilna
wersja to 1.2. Można ją pobrać z tego adresu: http://cesnet.dl.sourceforge.net/sourceforge/cvsgui/WinCvs120.zip
(~3,5MB) lub z oficjalnej strony http://www.wincvs.org.
Po pobraniu, rozpakowujemy archiwum na przykład korzystając z programu
Winzip (http://www.winzip.com).
Po rozpakowaniu klikamy na plik Setup.exe. Rozpoczyna się
właściwa instalacja.
Następnie klikamy cały czas na przycisk "Next", aż naszym oczom ukaże się monit z prośbą o ponowne uruchomienie komputera. Klikamy "Finish" i czekamy aż system ponownie się załaduje. Gdy to nastąpi oprogramowanie jest zainstalowane i gotowe do użycia.
Na początku utwórz gdzieś na swoim dysku folder, do którego chcesz pobrać
pliki. Może to być na przykład C:\PDDP. By utworzyć taki folder,
kliknij dwukrotnie "Mój komputer" następnie "C:". Teraz
gdzieś obok dostępnych ikonek kliknij prawym przyciskiem myszy i wybierz
"Nowy -> Folder". Wprowadź nazwę PDDP i naciśnij
Enter.
Teraz uruchom program WinCvs. By to zrobić klikamy:
"Start -> Programy -> Gnu -> WinCvs 1.2 -> WinCvs"
Po uruchomieniu pojawi się okno z różnymi poradami. Odznaczamy "Show Tips on StartUp" i klikamy "Close". Naszym oczom ukaże się okno o nazwie "WinCvs Preferences". W części oznaczonej jako "Enter the CVSROOT :" wprowadzamy:
:pserver:nazwa_konta@debian.linux.org.pl:/home/cvs
"nazwa_konta" zastępujemy przyznaną przez koordynatora nazwą. Następnie zmieniamy ustawienie "Authentication" tak by wskazywało na "passwd" file on the cvs server. Teraz przechodzimy na zakładkę "Globals" i odznaczamy opcję "Checkout read-only". Nic więcej nie zmieniamy i naciskamy OK.
Przyjrzyjmy się teraz jak wygląda główne okno programu. Górna część to tak jak
w większości programów różne menu oraz ikonki. W środkowej części mamy coś na
wzór Eksploratora Windows. Tutaj będziemy przeglądać pobrane
pliki oraz wykonywać większość operacji. Dolna część do okno komunikatów. To
istotne miejsce, gdyż tam CVS będzie informował nas o przebiegu swoich
operacji.
Zmienimy teraz jeszcze jedna opcję. Z menu "View" wybierz
"Browse Location -> Change...", a następnie wskaż katalog
C:\PDDP i kliknij OK.
Przejdźmy do pobierania plików z repozytorium. Zważ na to, że całe repozytorium to ponad 50MB! By to zrobić należy się najpierw zalogować. By to zrobić, klikamy menu "Admin -> Login...".
System poprosi nas o hasło (to które zatwierdził koordynator). Wprowadzamy je (w formie niezaszyfrowanej) i naciskamy Enter.
W dolnej części programu znajduje się okno komunikatów. Jeśli wszystko pójdzie w porządku, to ujrzymy:
*****CVS exited normally with code 0*****
Każdy inny komunikat oznacza, że coś poszło nie tak jak trzeba. Szczególnie chodzi o to by cyfra była równa 0.
Teraz pobierzmy pliki. Z menu "Create" wybierz "Checkout module...", a następnie w części "Enter the module name and path on the server :" wprowadzamy:
./
i klikamy OK. W oknie komunikatów powinny pojawić się wpisy tego typu:
cvs checkout -P ./ (in directory C:\PDDP)
cvs server: Updating .
cvs server: Updating CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg
cvs server: Updating pddp
U pddp/slownik.txt
U pddp/zasady.txt
cvs server: Updating pddp/pomoc
U pddp/pomoc/cvs.sgml
U pddp/pomoc/edytor.sgml
U pddp/pomoc/generuj
U pddp/pomoc/lista.sgml
U pddp/pomoc/pomoc.sgml
U pddp/pomoc/wstep.sgml
cvs server: Updating pddp/skrypty
U pddp/skrypty/generuj
U pddp/skrypty/pddp_check.pl
U pddp/skrypty/slownik
cvs server: Updating verbose
cvs server: Updating verbose/debian_install
U verbose/debian_install/config.sgml
U verbose/debian_install/cycle.sgml
U verbose/debian_install/debian_install.sgml
U verbose/debian_install/generuj
U verbose/debian_install/introduction.sgml
U verbose/debian_install/main.sgml
U verbose/debian_install/preface.sgml
U verbose/debian_install/synaptic.sgml
U verbose/debian_install/xfree.sgml
cvs server: Updating verbose/debian_kernel
U verbose/debian_kernel/building.sgml
U verbose/debian_kernel/compiling.sgml
U verbose/debian_kernel/config.sgml
U verbose/debian_kernel/debian_kernel.sgml
U verbose/debian_kernel/ext3.sgml
U verbose/debian_kernel/generuj
U verbose/debian_kernel/intro.sgml
U verbose/debian_kernel/preface.sgml
U verbose/debian_kernel/sound.sgml
*****CVS exited normally with code 0*****
Lista pobranych plików z pewnością będzie dłuższa (w momencie pisania tych słów
- wrzesień 2004 - repozytorium zajmuje ponad 120MB). Dla zobrazowania zasady
działania wystarczy nam jednak wycinek tej listy. W tym momencie w katalogu
C:\PDDP utworzonych zostało kilka podkatalogów
(CVSROOT, pddp itd.). W nich znajdują się różne
pliki, począwszy od dokumentów, które tłumaczymy, poprzez różnego rodzaju
skrypty wspomagające naszą pracę, na słowniku projektu kończąc. Reasumując
stworzyliśmy lokalną kopię repozytorium.
W powyższym przykładzie w części "Enter the module name and path on the server :" umieściłem ./ co oznacza główny katalog repozytorium. Częściej stosowane są jednak nazwy konkretnych katalogów. Wtedy należy wpisać na przykład:
pddp
Pobrany zostałby tylko jeden katalog o nazwie pddp. Główne
katalogi repozytorium zwane są również modułami. Jednakże dla potrzeb naszego
projektu najlepiej pobrać wszystkie katalogi, tak jak zostało to pokazane.
Wszelkie operacje wykonywane przez CVS mogą korzystać z kompresji by zmniejszyć zapotrzebowanie na przepustowość łącza. Jest to szczególnie przydatne dla osób korzystających z modemów. Aby włączyć kompresję należy wybrać "Preferences..." z menu "Admin", a następnie na zakładce "Globals" zaznaczyć "Use TCP/IP compression". Dodatkowo można ustawić poziom tej kompresji. Im większa liczba tym kompresja jest bardziej wydajna, ale wolniejsza.
Zanim przystąpisz do edytowania jakiegoś pliku, musisz zainstalować i
skonfigurować jakiś inny niż domyślny edytor. Windowsowy Notatnik
nie nadaje się do edycji plików naszego projektu, ponieważ nie obsługuje
odpowiedniego kodowania. W części Edytory/Windows
opisałem w jaki sposób pobrać, zainstalować i skonfigurować edytor
MiniPad.
Gdy masz już zainstalowany program MiniPad, trzeba ustawić
WinCvs by z niego korzystał. W tym celu z menu "Admin"
wybierz "Preferences...", następnie przejdź na zakładkę
"WinCvs". W części "Default viewer used to open files :"
wprowadź C:\MINIPAD\MINIPAD.EXE. Następnie zaznacz opcję
"Use on double click" i kliknij OK.
To wszystko. Od tej chwili WinCvs będzie korzystał z nowego
edytora.
Przed przystąpieniem do edycji jakiegoś pliku zawsze należy wykonać aktualizację lokalnej kopii. Pomocne mogą być również informacje dodatkowe.
By zaktualizować lokalną kopię repozytorium wystarczy kliknąć prawym
przyciskiem myszy na katalogu PDDP i wybrać "Update
selection...". Pojawi się okno o nazwie "Update settings". Nie
zmieniamy niczego i naciskamy "OK".
Więcej szczegółów i przykład jak może wyglądać wynik takiej operacji, znajduje się w dalszej części tego rozdziału. Na razie wystarczy Ci jedynie znajomość tej funkcji.
Po zmodyfikowaniu jakiegoś pliku, należy przesłać poprawki z powrotem do repozytorium.
By to zrobić kliknij prawym przyciskiem myszy na zmodyfikowanym pliku i wybierz "Commit selection...". Pojawi się okno o nazwie "Commit settings". W części "Enter the log message" należy wprowadzić opis dokonanych zmian. Następnie klikamy przycisk OK. W oknie komunikatów (dolna część) powinno pokazać się coś podobnego do poniższego przykładu:
cvs commit -m "przesyłam poprawki" cvs.sgml (in directory C:\PDDP\pddp\pomoc)
Checking in cvs.sgml;
/home/cvs/pddp/pomoc/cvs.sgml,v <-- cvs.sgml
new revision: 1.40; previous revision: 1.39
done
*****CVS exited normally with code 0*****
System poinformował nas, że przesłał plik do repozytorium oraz, że po nałożeniu naszych zmian przyporządkował plikowi nowy, kolejny numer wersji (w tym przypadku 1.40).
Może się zdarzyć, że podczas gdy my nanosiliśmy poprawki na jakiś plik, w tym samym momencie robił to ktoś inny. Co więcej, załóżmy, że ta druga osoba przesłała już swoje zmiany do repozytorium. Co to oznacza?
Jak łatwo się domyśleć teraz nasze poprawki nie odnoszą się już do najnowszej wersji dokumentu. Co się stanie gdy spróbujemy przesłać nasze poprawki do repozytorium ?
Załóżmy, że wcześniej pobraliśmy z repozytorium plik cvs.sgml w
wersji 1.45. Dokonaliśmy własnych poprawek i teraz chcemy je przesłać.
Zgodnie z wcześniejszym podrozdziałem klikamy prawym przyciskiem myszy na tym
pliku i wybieramy "Commit selection...". Następnie wprowadzamy opis
dokonanych zmian i naciskamy OK.
W oknie komunikatów pojawi się coś takiego:
cvs commit -m konflikt cvs.sgml (in directory C:\PDDP\pddp\pomoc)
cvs server: Up-to-date check failed for `cvs.sgml'
cvs [server aborted]: correct above errors first!
*****CVS exited normally with code 1*****
Jak widać przesłanie nie powiodło się. CVS poinformował nas, że nasze modyfikacje nie odnoszą się do najświeższej wersji z repozytorium. Prosi o poprawienie tego. Sposób poprawienia zależy jednak od tego czy nasze zmiany znajdują się w tej samej części pliku czy nie. Poniżej opisuję obie sytuacje:
W takim przypadku system CVS powinien poradzić sobie z połączeniem naszych
zmian ze zmianami poprzednika i utworzeniem jednego pliku wynikowego. Powinien
to zrobić podczas aktualizacji lokalnej kopii repozytorium. Spróbujmy zatem.
Klikamy prawym przyciskiem myszy na katalogu PDDP i wybieramy
"Update selection...". W oknie "Update settings" nic nie
zmieniamy i naciskamy OK. Komunikaty powinny wyglądać mniej więcej tak:
cvs update -P (in directory C:\PDDP\)
cvs server: Updating .
cvs server: Updating CVSROOT
cvs server: Updating pddp
cvs server: Updating pddp/pomoc
RCS file: /home/cvs/pddp/pomoc/cvs.sgml,v
retrieving revision 1.45
retrieving revision 1.46
Merging differences between 1.45 and 1.46 into cvs.sgml
M pddp/pomoc/cvs.sgml
cvs server: Updating pddp/skrypty
cvs server: Updating verbose
cvs server: Updating verbose/debian_install
cvs server: Updating verbose/debian_kernel
*****CVS exited normally with code 0*****
CVS przegląda całą lokalną kopię repozytorium i porównuje ją z główną
znajdującą się na serwerze. Pobiera informacje o zmianach w pliku
cvs.sgml i stara się połączyć je z naszą zmienioną wersją.
Informuje o tym w linii "Merging...". Operacja zakończyła się
sukcesem.
Dodatkowo CVS zapisuje plik oryginału z przed połączenia zmian. W naszym
przypadku plik ten otrzymał nazwę .#cvs.sgml.1.45, więc jak widać
w nazwie jest zapisana wersja. Plik ten jest zapisywany na wypadek gdybyśmy
chcieli sami sprawdzić czy CVS poprawnie połączył zmiany. Jeśli nie chcemy
tego robić można ten plik usunąć. Trzeba tego dokonać z poza programu
WinCvs. Można wykorzystać na przykład Eksploratora
Windows.
Teraz pozostaje nam przesłanie pliku z połączonymi zmianami do repozytorium. Robimy to dokładnie tak jak przedtem klikając na pliku prawym przyciskiem myszy i wybierając "Commit selections...". W oknie "Commit settings" wprowadzamy komentarz i klikamy OK.
A oto wynik w oknie komunikatów:
cvs commit -m "poprawiony konflikt" cvs.sgml (in directory C:\PDDP\pddp\pomoc)
Checking in cvs.sgml;
/home/cvs/pddp/pomoc/cvs.sgml,v <-- cvs.sgml
new revision: 1.47; previous revision: 1.46
done
*****CVS exited normally with code 0*****
Tym razem nasze poprawki zostały przesłane i naniesione bez przeszkód.
Tutaj sytuacja trochę się komplikuje. Program komputerowy choćby nie wiem jak sprawnie napisany pozostanie programem. Nie posiada inteligencji i sam nie jest w stanie stwierdzić, które poprawki są prawidłowe. Czy te wprowadzone przez nas czy przez poprzednią osobę.
Aby przedstawić zasadę rozwiązywania problemów przy nakładających się na siebie zmianach posłużę się specjalnym przykładowym zdaniem, które będzie znajdować się w tym pliku i które będziemy modyfikować. Będzie to jedna linijka tak by łatwo można było wytłumaczyć na czym polega rozwiązywanie takich konfliktów. Oto nasze zdanie:
Ala ma kota.
Załóżmy, że pobraliśmy plik z repozytorium w wersji 1.47. Teraz stwierdziliśmy, że przykładowe zdanie należy zmodyfikować. Według nas ma ono brzmieć:
Ala ma małego kotka.
Ale niestety okazało się, że ktoś inny stwierdził, że to zdanie należy zmienić na:
Ala Kowalska nie ma kota.
Co więcej przesłał już swoją poprawkę do repozytorium i w tym momencie istnieje tam już wersja 1.48 z jego modyfikacją tego zdania. Ewidentnie mamy tu konflikt.
Co się stanie jak spróbujemy przesłać nasze poprawki ?
Oczywiście zostaną odrzucone z prośbą o aktualizację naszej kopii repozytorium (tak jak w przykładzie gdzie poprawki się nie nakładały). Nieświadomi, tego, że zmiany znajdujące się w głównym repozytorium konfliktują z naszymi (bo przecież nie możemy tego wiedzieć), przystępujemy do aktualizacji naszej kopii repozytorium.
Tak wyglądałby wynik takiej aktualizacji:
cvs update -P (in directory C:\PDDP\)
cvs server: Updating .
cvs server: Updating CVSROOT
cvs server: Updating pddp
cvs server: Updating pddp/pomoc
RCS file: /home/cvs/pddp/pomoc/cvs.sgml,v
retrieving revision 1.47
retrieving revision 1.48
Merging differences between 1.47 and 1.48 into cvs.sgml
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in pddp/pomoc/cvs.sgml
C pddp/pomoc/cvs.sgml
cvs server: Updating pddp/skrypty
cvs server: Updating verbose
cvs server: Updating verbose/debian_install
cvs server: Updating verbose/debian_kernel
*****CVS exited normally with code 0*****
Jak widać podczas aktualizacji mamy ostrzeżenie o konflikcie. Świadczy o tym linia:
rcsmerge: warning: conflicts during merge
Dodatkowo zostaje utworzony ukryty plik z zawartością z przed aktualizacji. W
tym przypadku nosi nazwę .#cvs.sgml.1.47. Jego zastosowanie
opisałem w poprzednim podrozdziale.
No dobrze, ale jak rozwiązać problem nakładających się zmian? Zmiany te wbrew pozorom zostały połączone, a jedynie miejsca konfliktowe są specjalnie oznaczone w pliku, który modyfikowaliśmy. W naszym przypadku miejsce konfliktu wygląda tak:
<<<<<<< cvs.sgml
Ala ma małego kotka.
======
Ala Kowalska nie ma kota.
>>>>>>> 1.24
System pokazuje nam obie wersje tego zdania. Zarówno naszą jak i poprzednika. Ty musisz zdecydować, która wersja jest poprawna. Ewentualnie jak połączyć obie wersje w całość, która w tym przypadku mogłaby wyglądać następująco:
Ala Kowalska ma lub nie ma małego kotka.
To jak zostaną połączone zmiany zależy od Ciebie. Gdy się już zdecydujesz, zmodyfikuj oznaczone miejsce. Zostaw tylko jedną wersję zdania i usuń linie zawierające <<<<<<< cvs.sgml, ======= oraz >>>>>>> 1.24. Musisz je usunąć! Inaczej będziesz otrzymywać ostrzeżenia, o nadal istniejących konfliktach.
Teraz możesz przesłać poprawioną wersję z powrotem do repozytorium. Robimy to dokładnie tak samo jak wcześniej. Kliknij na pliku prawym przyciskiem myszy i wybierz "Commit selection...". W oknie "Commit settings" wprowadź komentarz i naciśnij OK.
A oto jak może wyglądać informacja w oknie komunikatów:
cvs commit -m "konflikt rozwiązany" cvs.sgml (in directory C:\PDDP\pddp\pomoc)
Checking in cvs.sgml;
/home/cvs/pddp/pomoc/cvs.sgml,v <-- cvs.sgml
new revision: 1.49; previous revision: 1.48
done
*****CVS exited normally with code 0*****
Tym razem nasze poprawki zostały przesłane i naniesione bez przeszkód.
W większości wypadków koordynator troszczy się o dodawanie nowych plików do repozytorium. Może jednakże zaistnieć potrzeba zrobienia tego samemu.
Należy to jednak wcześniej oznajmić na liście dyskusyjnej, podając nazwę pliku i miejsce jego lokalizacji. Następnie należy poczekać na komentarz bardziej zaawansowanego użytkownika.
Obostrzenia takie występują ze względu na to, iż CVS prowadzi historię wszelkich operacji. Dodanie pliku jest bardzo proste, ale jego usunięcie już niekoniecznie. Dlatego każda taka modyfikacja powinna być przemyślana i skonsultowana z resztą grupy. A już najlepiej po prostu sygnalizować potrzebę nowego pliku i czekać, aż założy go koordynator lub ktoś bardziej zaawansowany.
Aby jednak instrukcja, którą czytasz była pełniejszym opisem systemu CVS, wypada objaśnić sposób dodawania pliku.
Załóżmy, że chcesz dodać plik o nazwie edytor.sgml w podkatalogu
pddp/pomoc/. Najpierw musisz utworzyć taki plik za pomocą
jakiegoś zewnętrznego programu. Nie można tego zrobić w WinCvs.
Gdy odpowiedni plik znajduje się już w podkatalogu zaznacz go i z menu
"Modify" wybierz "Add selection".
W oknie komunikatów ujrzysz:
cvs add edytor.sgml (in directory C:\PDDP\pddp\pomoc)
cvs server: scheduling file `pddp/pomoc/edytor.sgml' for addition
cvs server: use 'cvs commit' to add this file permanently
*****CVS exited normally with code 0*****
CVS poinformował nas, że plik ten został umieszczony w kolejce oczekującej na dodanie do głównego repozytorium. W tym momencie plik nie został jeszcze przesłany! W trzeciej linii jesteśmy powiadamiani, że należy o fakcie utworzenia pliku przesłać informację do repozytorium.
Postępujemy więc według tej wskazówki. Ta część wygląda tak samo jak przy przesyłaniu poprawek zmienianych plików. Klikamy prawym przyciskiem myszy na pliku i wybieramy "Commit selection...". W oknie "Commit settings" wprowadzamy komentarz i klikamy OK. W oknie komunikatów ujrzymy:
cvs commit -m "nowy plik" (in directory C:\PDDP\pddp\pomoc)
RCS file: /home/cvs/pddp/pomoc/edytor.sgml,v
done
Checking in pddp/pomoc/edytor.sgml;
/home/cvs/pddp/pomoc/edytor.sgml,v <-- edytor.sgml
initial revision: 1.1
done
Jak widać niewiele różni się to od zwykłego przesyłania zmienionych plików. Otrzymujemy jedynie dodatkowe informacje o tym, że jest to pierwsza wersja tego pliku.
To również funkcja z której nie będziesz raczej korzystać. Ale tak jak poprzednio objaśnię ją, dla pełniejszego opisu systemu CVS.
Załóżmy, że chcesz usunąć plik, który przed chwilą dodaliśmy, a więc plik o
nazwie edytor.sgml z podkatalogu pddp/pomoc/.
By usunąć plik z menu "Modify" wybierz "Remove selection". W oknie komunikatów ujrzysz:
'edytor.sgml' has been moved successfully to the recycle bin...
cvs remove edytor.sgml (in directory C:\PDDP\pddp\pomoc)
cvs server: scheduling `edytor.sgml' for removal
cvs server: use 'cvs commit' to remove this file permanently
*****CVS exited normally with code 0*****
Tym razem zostaliśmy poinformowani, że plik edytor.sgml został
umieszczony w kolejce do usunięcia. W drugiej linii znowu mamy informację, o
tym, że żeby go całkowicie usunąć z głównego repozytorium należy powiadomić o
tym system CVS. Robimy to klikając prawym przyciskiem na pliku i wybierając
"Commit selection...". W oknie "Commit settings"
wprowadzamy komentarz i naciskamy OK. W oknie komunikatów ujrzymy:
cvs commit -m "usuwam plik" edytor.sgml (in directory C:\PDDP\pddp\pomoc)
Removing edytor.sgml;
/home/cvs/pddp/pomoc/edytor.sgml,v <-- edytor.sgml
new revision: delete; previous revision: 1.7
done
*****CVS exited normally with code 0*****
Otrzymujemy informację o usunięciu pliku. Teraz pozostaje jeszcze fizyczne
usunięcie go z naszej lokalnej kopii repozytorium. Trzeba to zrobić z poza
programu WinCvs. Można wykorzystać na przykład Eksploratora
Windows. Musisz usunąć ten plik! W przeciwnym wypadku
będziesz otrzymywać komunikaty o nieznanym pliku.
Ta możliwość również nie powinna Ci być potrzebna. Takimi rzeczami zajmuje się koordynator. Poza tym CVS nie przewiduje takiej operacji. Należy plik usunąć i dodać ze zmienioną nazwą. Poszczególne czynności są opisane w poprzednich podrozdziałach.
Nawet nie próbuj!
O ile w przypadku plików, pomyłki da się w miarę prosto "odkręcić", to z katalogami wygląda to o wiele gorzej.
Dlatego też w naszym repozytorium obowiązuje bezwzględny zakaz tworzenia katalogów. Potrzebę istnienia jakiegoś katalogu należy zgłosić na liście dyskusyjnej. Zostanie to przedyskutowane i wtedy koordynator założy odpowiedni katalog w dobrze przemyślanej lokalizacji, tak by nie okazało się w przyszłości, że trzeba zmienić jego nazwę lub umiejscowienie.
Jedynie dla celów informacyjnych (a nuż ktoś chce stworzyć własne repozytorium) napiszę, że katalogi dodaje się analogicznie do plików. Usuwanie niestety wymaga ingerencji w "środku" bazy danych całego repozytorium i jest operacją bardzo niezalecaną.
Wystąpił już wcześniej podrozdział o podobnej nazwie. Obiecałem w nim, że później znajdziesz więcej informacji na ten temat. Właśnie nadszedł czas spełnienia obietnicy.
Wiele razy korzystaliśmy z funkcji "Update selection...", które służy do synchronizacji naszej kopii lokalnej z głównym repozytorium. Teraz bliżej przyjrzymy się temu co zwraca takie polecenie, a może to wyglądać tak:
cvs update -P (in directory C:\PDDP\)
? pddp/informacja
cvs server: Updating .
cvs server: Updating CVSROOT
cvs server: Updating pddp
cvs server: Updating pddp/pomoc
P pddp/pomoc/cvs.sgml
U pddp/pomoc/edytor.sgml
C pddp/pomoc/wstep.sgml
M pddp/pomoc/pomoc.sgml
cvs server: Updating pddp/skrypty
cvs server: Updating verbose
cvs server: Updating verbose/debian_install
R verbose/debian_install/intro.sgml
cvs server: Updating verbose/debian_kernel
A verbose/debian_kernel/sound.sgml
*****CVS exited normally with code 0*****
Jak widać przy plikach pojawiają się tajemnicze znaki, takie jak ?, P, U, C, M, R oraz A. Warto wiedzieć co one oznaczają, ponieważ są to istotne dla nas informacje.
Znaczenia poszczególnych znaków są następujące:
Jeśli ilość wyświetlanych przez WinCVS informacji wydaje nam się za duża, można sprawić by program był mniej ,,gadatliwy''. W tym celu należy wybrać "Preferences..." z menu "Admin", a następnie na zakładce "Globals" zaznaczyć opcję "Quiet mode (less messages)".
I jeszcze jedna dodatkowa informacja. Jeśli do repozytorium zostały dodane jakieś katalogi (z plikami) to zwykła funkcja "Update selection..." nie ,,zauważy'' ich i tym samym nie pobierze. W takich przypadkach należy po wybraniu funkcji "Update selection..." zaznaczyć dodatkową opcję "Create missing directories that exist in the repository". W wyjątkowych sytuacjach, tj. gdyby nadal nie udało się pobrać nowych katalogów, można zaznaczyć jeszcze opcję "Reset any sticky date/tag/'-k' option".
Dzięki temu, że CVS trzyma w swojej bazie informacje o każdej
wersji pliku, możliwe jest obejrzenie różnic pomiędzy dowolnymi wersjami.
Spróbujmy wyświetlić różnice pomiędzy wersją 1.16 oraz 1.15 pliku
lista.sgml z podkatalogu pddp/pomoc/. W tym celu
klikamy na pliku i wybieramy "Diff selection". W oknie "Diff
settings" zaznaczamy "Compare two revisions/tags/branches/dates
:" i wprowadzamy w pierwszym okienku 1.16, a w drugim
1.15. Oto wynik takiej funkcji:
cvs diff -r 1.16 -r 1.15 lista.sgml (in directory C:\PDDP\pddp\pomoc)
Index: lista.sgml
===================================================================
RCS file: /home/cvs/pddp/pomoc/lista.sgml,v
retrieving revision 1.16
retrieving revision 1.15
diff -r1.16 -r1.15
12c12
< rozsyłana do skrzynek pocztowych wszystkich, którzy są na liście zapisani.
---
> rozsyłana na skrzynki pocztowe wszystkich, którzy są na liście zapisani.
*****CVS exited normally with code 1*****
W powyższym przykładzie widać, że pomiędzy tymi wersjami nastąpiła zmiana jedynie jednego zdania. Najpierw wyświetlony jest tekst, który znajduje się w wersji 1.16, a później ten z wersji 1.15. Obie wersje rozdzielone są znakami ---.
Niektóre funkcje WinCvs posiadają skróty klawiaturowe. Na
przykład zamiast klikać prawym przyciskiem myszy i wybierać "Commit
selection..." wystarczy wcisnąć kombinację "CTRL+M". Poniżej
lista przedstawiająca skróty dla funkcji wykorzystanych w tym dokumencie:
Opisałem tylko część możliwości programu WinCvs, ale przy pracy w
naszym projekcie wystarczy to w zupełności. Więcej informacji możesz uzyskać w
pomocy do programu lub na stronie domowej projektu CVS, której adres to
www.cvshome.org. Koniecznie
przeczytaj informacje ogólne o pracy z systemem CVS znajdujące się w części
Informacje dodatkowe.
To już prawie wszystko co powinieneś wiedzieć o korzystaniu z systemu CVS. Poniżej jeszcze tylko kilka uwag odnośnie pracy.
Synchronizuj swoją lokalną kopię z głównym repozytorium jak najczęściej. Przystępując do pracy nad plikiem najpierw go zaktualizuj. Gdy skończysz pracę, prześlij poprawki jak najszybciej. Gdy zamierzasz edytować dużą część pliku przesyłaj poprawki w trakcie pracy (na przykład po skończeniu poszczególnych rozdziałów). To wszystko pozwoli zminimalizować ryzyko wystąpienia konfliktów.
Jak już wspomniałem CVS używa numerów wersji by móc rozróżniać zmiany w plikach. Jako, że te numery wersji nie dla wszystkich wydają się oczywiste to poniżej małe objaśnienie.
Załóżmy, że mamy numerki 1.2 i 1.12. Który z nich jest większy? Mogłoby się wydawać, że 1.2 gdyż liczba po kropce jest większa niż w drugim numerze. Nic bardziej mylnego. Porównujemy całe liczby występujące po znaku kropki, więc w tym wypadku 2 oraz 12. Oczywiste jest, że 12 jest większe, a tym samym 1.12 jest wersją powstałą później, a więc bardziej zaawansowaną niż wersja 1.2.
Powiadom, poprzez listę dyskusyjną, innych grupowiczów o tym co edytujesz. Nie musisz tego oczywiście robić w przypadku poprawiania małych błędów. Na przykład literówek. Ale przy przystępowaniu do tłumaczenia dużego pliku lub jego części jest to bardzo wskazane. Nikt nie będzie wtedy grzebał w tym samym miejscu i są mniejsze szanse na konflikty.
Jeśli masz jakiś problem, to nie próbuj samemu kombinować i wykorzystywać
bardziej zaawansowane i co gorsza nieznane Ci funkcje CVS.
Pamiętaj, że masz nieograniczony dostęp do repozytorium i możesz niechcący
dokonać poważnych szkód. W razie problemów pytaj więc na liście dyskusyjnej, a
z pewnością ktoś Ci pomoże.
Często na liście pojawia się stwierdzenie typu "commit". Jeśli ktoś stwierdza, że zrobił "commit" to oznacza ono po prostu, że ktoś przesłał swoje poprawki do CVS. Analogicznie jeśli ktoś prosi o "commit", to oznacza, że prosi o przesłanie poprawek.
Mogą również pojawić się "koślawe spolszczenia" tego określenia. Na przykład "commitnąłem", "kommitnąłem", "kommitłem" czy coś w tym rodzaju.
Istnieje możliwość przeglądania repozytorium poprzez strony WWW.
Jeden z interfejsów dostępny jest pod adresem http://debian.linux.org.pl/cgi-bin/viewcvs.cgi
Na głównej stronie widać wszystkie katalogi. Możesz się po nich poruszać tak j
ak po drzewie katalogów w swoim systemie operacyjnym.
Klikając na jakiś plik, otrzymasz informacje o poszczególnych wersjach wraz z komentarzami. Najbardziej przydatną funkcją jest przeglądanie zmian dokonanych pomiędzy poszczególnymi wersjami. System prezentuje je w bardzo przystępnej (pokolorowanej) formie. By wyświetlić takie informacje należy na dole strony opisującej jakiś plik, wprowadzić numery wersji, a następnie kliknąć "Get Diffs".
Klikając "Display revisions graphically" otrzymasz graficzne drzewo prezentujące kolejne zmiany.
Zawartość każdego katalogu możesz pobrać klikając "Download tarball". System automatycznie wygeneruje najnowsze archiwum.
Drugim dostępnym interfejsem jest CVS Monitor. Można go znaleźć
pod adresem http://debian.linux.org.pl/cgi-bin/cvsmonitor/cvsmonitor.pl.
Oferuje podobną funkcjonalność do ViewCVS, a dodatkowo różne
statystyki, informacje o ostatnio przesłanych zmianach itp.
Ten rozdział powstał po to, by pomóc w doborze odpowiedniego edytora do pracy przy tłumaczeniach. Wbrew pozorom nie jest to mało istotna sprawa. Porządny edytor z kolorowaniem składni może sprawić, że praca będzie bardziej wydajna i przyjemna.
Rozdział podzielony jest na dwie części. Pierwsza dotyczy systemu Linux, a druga Windows. W przypadku tego drugiego systemu operacyjnego, dochodzi jeszcze kwestia rozwiązania problemu z nieprawidłowym kodowaniem polskich znaków diakrytycznych. Sposób poradzenia sobie z tym problemem jest również opisany w tym rozdziale.
W systemie Linux ilość dostępnych edytorów jest ogromna. Większość z nich oferuje kolorowanie składni, a wszystkie obsługują standardy wymagane przy tłumaczeniach.
Nie będę opisywał wszelkich zagadnień związanych z konfiguracją edytorów pod systemem Linux, gdyż wybiega to poza temat tego przewodnika. Wymienię tylko co bardziej popularne edytory i spróbuję je scharakteryzować.
Reasumując bardzo dobry edytor, jednakże trzeba poświęcić trochę czasu by się do niego przyzwyczaić. Stracony czas z pewnością jednak zostanie wynagrodzony.
Istnieje również wersja skompilowana z biblioteką GTK. Nosi nazwę
GVim.
Vim'em od lat toczą się święte wojny
użytkowników. Bardziej fanatyczni użytkownicy deklarują oddanie swego
istnienia w obronie ulubionego edytora.
Posiada ogromne możliwości, jest wręcz systemem operacyjnym, w którym można
uruchomić specjalnie przygotowane wersje klienta poczty, news i wielu innych.
W zakresie edycji dokumentów posiada możliwości porównywalne do
Vim'a, choć jego użytkownicy z pewnością stwierdzą, że bije go pod
tym względem na głowę, ale tak już jest ze świętymi wojnami.
Midnight Commander. Obsługa nie powinna nastręczać trudności
użytkownikom przesiadającym się z systemu Windows i mającym kontakt z programem
edit.exe lub edytorami dostępnymi w Norton
Commanderze lub Dos Navigatorze. Posiada możliwość
kolorowania składni.
Standardowo dostępny edytor tekstu Notatnik mógłby być z
powodzeniem używany do tłumaczeń gdyby nie jedno ale. Nie obsługuje on
kodowania znaków w standardzie ISO-8859-2, a takie jest używane w dokumentach,
które tłumaczymy.
Są trzy sposoby rozwiązania problemu kodowania w systemie Windows:
My skorzystamy z pierwszego sposobu. Dodatkowo uzyskamy kolorowanie składni co
również nie jest bez znaczenia. Jest wiele darmowych edytorów, które bez
problemu mogą zastąpić windowsowy Notatnik, a dodatkowo oferują
wiele funkcji, których oryginał nie posiada. Jednym z takich edytorów jest
Tiger II MiniPad autorstwa, naszego rodaka, Jacka Szarapy.
Program możemy pobrać ze strony http://tiger.rubikon.pl/t2mini.php.
Zapisujemy archiwum gdzieś na swoim dysku, a następnie na przykład przy pomocy
programu WinZip rozpakowujemy je do katalogu
C:\MINIPAD.
Po uruchomieniu programu naszym oczom ukaże się monit z prośbą o wybór wersji językowej. Klikamy "Polski interfejs". Załaduje się główne okno programu. Dodatkowo pokaże się okienko "Podpowiedzi". Zaznaczamy "Nie pokazuj więcej tego okienka" i klikamy "Zamknij".
Z menu "Opcje" wybieramy "Ustawienia". Na zakładce "Zapisywanie" ustawiamy opcję "Domyślna strona kodowa" na "ISO-8859-2" i klikamy "OK".
Teraz pozostało nam jedynie skonfigurować WinCvs by korzystał z
tego edytora. Jak to zrobić jest dokładnie opisane w części WinCvs/Domyślny edytor.
Bez względu na to jakiego edytora używasz, ważne jest by ustawić go tak aby zawijał linie gdzieś w okolicach 76 znaku. To dość istotne, gdyż sporo ludzi pracuje w środowisku tekstowym i powierzchnia ich edytorów najczęśćiej ogranicza się do 80 znaków.
Oczywiście nie zawijamy długich odsyłaczy i innych tego typu elementów, które muszą być w całości.
DebianDoc jest językiem znaczników opartym na SGML (Standard Generalized Markup Language), który można określić jako "Standardowy Język Uogólnionego Znakowania". Generalnie SGML jest metajęzykiem służącym do tworzenia innych języków. Jednym z takich języków jest właśnie DebianDoc. Zawiera on kilkanaście specjalnych znaczników, dzięki którym możliwe jest tworzenie struktury dokumentu.
Ponieważ pliki zapisane w tym języku są zwykłymi plikami tekstowymi zawierającymi jedynie specjalne znaczniki typu <znacznik> lub </znacznik>. Dzięki temu można je edytować w dowolnym edytorze tekstowym, nie są potrzebne żadne specjalne narzędzia. Poza tym wielką zaletą formatów opartych na SGML jest możliwość wygenerowania pliku wynikowego w dowolnym formacie.
Otrzymanie pliku PDF, PS (PostScript), HTML czy zwykłego pliku tekstowego to żaden problem. Wystarczy wprowadzić jedno polecenie.
Oto przykładowy plik:
<!doctype debiandoc system [
]>
<book>
<title>Instrukcja gaszenia światła</title>
<author>
<name>Bartosz Feński aka fEnIo</name>
<email>fenio@debian.org</email>
</author>
<version>v0.2 <date></version>
<copyright>
<copyrightsummary>
Copyright © 2003-2006 Bartosz Feński aka fEnIo
</copyrightsummary>
<p>
Instrukcja powstała by zaprezentować możliwości formatu DebianDoc. Żadnych
gwarancji nie uwzględnia się. Używaj na własną odpowiedzialność.
</copyright>
<chapt id="wstep">Wstęp
<sect>Wprowadzenie
<p>
W instrukcji opisane zostaną sposoby na zgaszenie światła.
</sect>
<sect>Gaszenie światła
<p>
Są trzy podstawowe sposoby gaszenia światła:
<list>
<item>Przełączenie kontaktu
<item>Wykręcenie żarówki
<item>Wykręcenie stopek
</list>
</sect>
<sect>Ostrzeżenie
<p>
<strong>Uważaj</strong> by nie poraził Cię prąd.
</sect>
</chapt>
</book>
Jak widać w dokumencie występują różne charakterystyczne wyrazy pomiędzy znakami < oraz >. Są to tak zwane znaczniki. One definiują strukturę dokumentu. Wszystkie znaczniki występują w dwóch formach. Otwierającej: <znacznik>, oraz zamykającej: </znacznik> W niektórych wypadkach można jednak pominąć znacznik zamykający, ponieważ ustalono, że zamykał je będzie kolejny znacznik otwierający.
Można spotkać jeszcze jeden rodzaj znaczników. Wyglądają na przykład tak:
<package/xlib6/
To takie swego rodzaju uproszczenie, a oznacza ni mniej ni więcej tylko:
<package>xlib6</package>
Zastosowanie jest dość oczywiste. Pierwsza forma jest znacznie krótsza, a przez to dla niektórych wygodniejsza. Wadę ma praktycznie tylko jedną. Jest to trochę mniej czytelne. Nie zmienia to jednak faktu, że jest to stosowane i nie należy tego traktować jako błąd, a tymbardziej nie należy w polskich tłumaczeniach podmieniać takich znaczników na te czytelniejsze, bo wprowadzi to tylko niepotrzebne zamieszanie.
Wszystko co znajduje się poza znacznikami to zwykły tekst, który jest przez te znaczniki odpowiednio formatowany. Na przykład wszystko co znajduje się pomiędzy znacznikami <strong> oraz </strong> zostanie w wynikowym dokumencie pogrubione. W powyższym przykładzie wykorzystałem tylko część dostępnych w DebianDoc znaczników. Wszystkie opisane są w następnym podrozdziale.
Wszystkie znaczniki posiadają swój odpowiednik zamykający, chyba, że zaznaczono inaczej. Poniżej lista wraz z krótkim opisem:
Ponieważ znaczniki oznaczane są znakami < oraz >. Co jednak gdy potrzebujemy w dokumencie umieścić po prostu znak < lub > ? Istnieją specjalne sekwencje pozwalające na wstawianie takich znaków. Oto ich skrócona lista:
Z formatu DebianDoc można bez problemu uzyskać następujące pliki wynikowe:
Z pewnością można uzyskać jeszcze więcej rodzajów, ale my w projekcie używamy tylko tych powyżej wymienionych.
Do generowania wspomnianych formatów służy, napisany na potrzeby projektu,
skrypt generuj. Więcej informacji o nim uzyskasz w rozdziale Generowanie dokumentów.
Tyle wiadomości z zakresu DebianDoc powinno Ci w zupełności do pracy w projekcie wystarczyć. Właściwie jedyne co powinieneś wiedzieć, to fakt, że tłumaczymy tylko to co znajduje się poza wszelkimi znacznikami. Grzebanie wewnątrz znaczników nie jest zalecane, chyba, że naprawdę wiesz co robisz. W przeciwnym wypadku, możesz doprowadzić do tego, że dokumentu nie będzie się dało przetworzyć na inny format.
Od tej reguły istnieją jednakże pewne wyjątki. Możesz o nich poczytać w rozdziale Praca/DebianDoc.
Zakładam, że czytając ten rozdział potrafisz już korzystać z listy dyskusyjnej jak i z repozytorium CVS. Nie obcy jest Ci również format DebianDoc, WML czy gettext. Masz także skonfigurowany odpowiedni system i jakiś edytor tekstowy, którym będziesz się posługiwać. Reasumując wiesz wszystko co jest potrzebne do rozpoczęcia pracy. Jeśli nie, to koniecznie przeczytaj poprzednie rozdziały.
W tym rozdziale dowiesz się co zrobić zanim zaczniesz tłumaczyć lub sprawdzać nasze teksty. Opisane są również sytuacje, które możesz napotkać przy codziennej pracy, oraz te rzadsze, ale równie ważne wydarzenia, które są naturalną konsekwencją naszych poczynań.
Na początku wypada jakoś powiadomić resztę grupowiczów o swojej obecności. W
swojej lokalnej kopii repozytorium w podkatalogu pddp/ masz
zapewne plik ludzie. Znajdują się w nim informacje o członkach
projektu. Przykładowy wpis wygląda tak :
Imię i nazwisko : Bartosz Feński
Ksywa : fEnIo
Konto CVS : fenio
E-mail : fenio@debian.org
Miejscowość : Skawina/Kraków
HTML : 5
SGML : 3
[X]SQL : 1
PHP : 2
CVS : 8
Grafika : 0
Angielski : 7
Funkcja : Tłumacz/korektor
Inne :
Jak widać oprócz podstawowych informacji takich jak godność, pseudonim, adres poczty elektronicznej, miejscowość czy funkcja są również złowrogo brzmiące linie typu [X]SQL. Postanowiliśmy, że każdy będzie się chwalił na jakim poziomie opanowane ma różnego rodzaju technologie, języki programowania oraz inne zdolności, które mogą być pomocne w projekcie. Przy każdej zdolności podajemy stopień jej opanowania w skali od 0 do 10. Im niższa liczba tym mniejsze umiejętności. Poszczególne linie mają następujące znaczenie:
Teraz gdy już wszystko jasne, pozostało Ci dodać odpowiedni wpis dotyczący Twojej osoby. Najprościej przekopiować istniejący wpis w odpowiednie miejsce i poprawić dane tak by odnosiły się do Ciebie. Postaraj się zachować porządek alfabetyczny. Gdy skończysz prześlij po prostu ten plik do repozytorium, a gdy koordynator zauważy zmianę, to z pewnością pojawi się Twoje nazwisko na naszej stronie w dziale "Kim jesteśmy".
Inni uczestnicy projektu wiedzą już o Twoim istnieniu. Teraz zapewne chcesz zacząć coś tłumaczyć lub sprawdzać. Trzeba powiadomić o tym resztę grupy.
W podkatalogu pddp/stan w swojej lokalnej kopii repozytorium
znajdują się różne pliki. Każdy tłumaczony przez nas dokument posiada własny
plik o takiej samej nazwie jak katalog w którym się znajduje. W nich
umieszczone są informacje o tym co kto w danym momencie robi. Tak więc zanim
przystąpisz do tłumaczeń lub korekty zaglądnij do odpowiedniego pliku, aby
sprawdzić czy to co chcesz tłumaczyć lub sprawdzać nie jest przypadkiem zajęte
przez kogoś innego. Każdy z tych plików ma pewną ustaloną strukturę. Poniżej
przykładowy wpis z pliku quick-reference:
[edit.sgml]
Tłumaczenie:
Mariusz Strzelecki
Stan:
skończone
Aktualizacje:
09.06.2003 [X] fEnIo, 15.06.2003
04.05.2003 [X] fEnIo, 25.05.2003
21.04.2003 [X] fEnIo, 02.05.2003
Korekta:
Oskar Ostafin
Jacek Politowski, 16.06.2003
Uwagi:
Kilka słów komentarza. W nawiasie kwadratowym podana jest nazwa pliku z danego dokumentu. Poniżej wpisany jest tłumacz (lub tłumacze) oraz stan tłumaczenia. Następnie wyszczególnione są aktualizacje wraz z osobami, które je przeprowadziły. Data po lewej stronie jest datą synchronizacji angielskiej wersji, a ta po prawej datą aktualizacji polskiego odpowiednika. Kolejna pozycja to korekta. Wypisani są tutaj ludzie, którzy ją przeprowadzają, a dodatkowo dopisują datę jej ukończenia. Ostatnie pole to uwagi. Tutaj można wpisywać powody przerwania pracy i tym podobne rzeczy.
Jeśli przy jakimś pliku nie ma nazwisk lub dany autor napisał, że nie może w danym momencie tłumaczyć, to możesz zająć się tym plikiem. Jeśli chodzi o korektę, to może ją przeprowadzać nieskończenie wiele osób.
Czasem jeśli tłumaczony dokument jest jednym dużym plikiem, to wpisy w
pddp/stan/ mogą trochę się różnić, ale zorganizowane są na
podobnej zasadzie i zorientowanie się jak to jest zrobione raczej nie nastręcza
zbyt dużych problemów.
Pamiętaj! Należy tłumaczyć i sprawdzać tylko pliki z
podkatalogów pl/, a nie z en/.
Właściwie rzecz biorąc w ogóle nie powinny interesować Cię pliki z podkatalogów o nazwach kojarzących się z językiem angielskim czyli en/ lub english. W tych podkatalogach grzebie głównie koordynator.
Zarówno Ty jak i reszta grupowiczów wie już co chcesz tłumaczyć. No to czas zacząć. Na początku konieczne jest zapoznanie się z dwoma plikami.
Pierwszy z nich zawiera przyjęte przez nas i obowiązujące wszystkich członków
projektu reguły dotyczące tłumaczeń. Znajduje się w Twojej lokalnej kopii
repozytorium, w podkatalogu pddp/. Plik nazywa się
zasady.txt. Jest to lektura obowiązkowa dla ludzi chcących brać
udział w naszym przedsięwzięciu.
Drugi plik to slownik.txt, który znajduje się w tym samym
podkatalogu. Jest to nasz wewnętrzny słownik opisujący niektóre wyrazy i
zwroty, które sprawiały problemy lub ze względu na mnogość możliwych tłumaczeń
zostały tu umieszczone by ujednolicić nasze dzieła.
Podrozdział Przeszukiwanie słownika opisuje przydatny przy pracy ze słownikiem skrypt.
Nasz wewnętrzny słownik jest bardzo ubogi i prawdopodobnie niewiele się powiększy. Bierze się to z faktu, iż ma on za zadanie jedynie wyjaśnianie pewnych wątpliwości. Inne słowniki, które zapewne są bogatsze w zasób słów i mogą być doskonałym wsparciem podczas tłumaczeń to: