PDDP - Jak pomóc? ----------------- Bartosz Feński aka fEnIo v0.64 11 kwiecień 2006 ------------------------------------------------------------------------------- Prawa autorskie --------------- Copyright (C) 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. ------------------------------------------------------------------------------- Spis treści ----------- 1. Wstęp 1.1. Wprowadzenie 1.2. Dlaczego ktoś miałby Wam pomagać ? 1.3. Chcę pomóc, ale nie znam angielskiego. 1.4. Chcę pomóc, ale używam systemu Windows. 1.5. Chcę pomóc, ale nie wiem jak. 2. Lista dyskusyjna 2.1. Co to jest lista dyskusyjna? 2.2. Dlaczego stosujecie listę dyskusyjną? 2.3. Jak zapisać się na listę? 2.4. Jak włączyć się do dyskusji? 2.5. Netykieta 2.5.1. Odpowiadamy pod cytatem 2.5.2. Usuwamy zbędne cytaty 2.5.3. Usuwamy sygnaturki 2.5.4. Zawijamy linie 2.5.5. Nie używamy formatu HTML 2.5.6. Nie wysyłamy załączników 2.5.7. Piszemy krótko, zwięźle 2.5.8. Piszemy na temat 2.5.9. Dane personalne 2.5.10. Długość sygnaturki 2.5.11. Delimeter sygnaturki 2.5.12. Duże litery 2.5.13. Staranność 2.5.14. Tematy wiadomości 2.5.15. Cytowanie 2.6. Jak rozpocząć nowy wątek? 2.7. Archiwum. 2.8. Ustawienia. 2.8.1. Jak wypisać się z listy? 2.8.2. Jak odzyskać hasło? 2.9. Lista informacyjna 2.10. Podsumowanie 3. CVS 3.1. Co to jest CVS? 3.2. Dlaczego stosujecie CVS? 3.3. Jak z tego korzystać? 3.4. Mam konto. Co dalej? 3.4.1. Linux 3.4.1.1. Wymagane oprogramowanie 3.4.1.2. Pobieranie plików z repozytorium. 3.4.1.3. Aktualizacja lokalnej kopii repozytorium 3.4.1.4. Przesyłanie poprawek 3.4.1.5. Konflikty 3.4.1.6. Dodawanie pliku 3.4.1.7. Usuwanie pliku 3.4.1.8. Zmiana nazwy pliku 3.4.1.9. Dodawanie i usuwanie katalogów 3.4.1.10. Aktualizacja lokalnej kopii repozytorium - dodatkowe informacje. 3.4.1.11. Różnice pomiędzy wersjami 3.4.1.12. Skróty i synonimy 3.4.1.13. Dalsze informacje 3.4.2. Windows 3.4.2.1. Wymagane oprogramowanie 3.4.2.2. Pobieranie plików z repozytorium 3.4.2.3. Domyślny edytor 3.4.2.4. Aktualizacja lokalnej kopii repozytorium 3.4.2.5. Przesyłanie poprawek 3.4.2.6. Konflikty 3.4.2.7. Dodawanie pliku 3.4.2.8. Usuwanie pliku 3.4.2.9. Zmiana nazwy pliku 3.4.2.10. Dodawanie i usuwanie katalogów 3.4.2.11. Aktualizacja lokalnej kopii repozytorium - dodatkowe informacje 3.4.2.12. Różnice pomiędzy wersjami 3.4.2.13. Klawisze skrótów 3.4.2.14. Dalsze informacje 3.5. Informacje dodatkowe 3.5.1. Częste aktualizacje 3.5.2. Wersjonowanie plików 3.5.3. Informuj co robisz 3.5.4. Kto pyta, nie błądzi 3.5.5. Commit 3.6. Dostęp do CVS przez stronę WWW 3.6.1. ViewCVS 3.6.2. CVS Monitor 4. Edytory 4.1. Dlaczego taki rozdział? 4.2. Linux 4.3. Windows 4.3.1. Pobieranie i instalacja 4.3.2. Konfiguracja 4.4. Informacje ogólne 5. DebianDoc 5.1. Co to jest DebianDoc? 5.2. Dlaczego używacie DebianDoc? 5.3. Jak wygląda DebianDoc? 5.4. Znaczniki dostępne w DebianDoc 5.5. Znaki specjalne 5.6. Generowanie plików wynikowych 5.7. Podsumowanie 6. Praca 6.1. Zanim zaczniesz 6.2. Co dalej? 6.3. Jak tłumaczyć? 6.4. Dzień po dniu... 6.4.1. Nie wiem jak przetłumaczyć 6.4.2. Znaczniki DebianDoc 6.4.2.1. "Entitki" 6.4.2.2. Odsyłacze 6.5. Tydzień po tygodniu... 6.5.1. Aktualizacja tłumaczeń 6.5.2. Głosowanie 6.6. Uwagi dotyczące korekty 6.7. Czystki 6.8. Kącik deweloperów 7. Tłumaczenie stron WWW 7.1. Wstęp 7.2. Co to jest WML? 7.3. Dlaczego WML? 7.4. WML na tapecie 7.5. Na co należy zwracać uwagę? 7.6. Pliki `.data' 7.7. Tłumaczenia 7.7.1. Tłumaczenie nowego pliku 7.7.2. Tłumaczenie na raty 7.7.3. Aktualizacja starego pliku 7.8. Pytania 8. Tłumaczenie szablonów DebConf 8.1. Wstęp 8.2. Co to jest gettext? 8.3. Dlaczego gettext? 8.4. Gettext na tapecie 8.5. Komentarze 8.5.1. Komentarze użytkowników 8.5.2. Komentarze automatyczne 8.6. Informacje 9. DWN 9.1. Co to jest DWN? 9.2. Wymagane oprogramowanie 9.3. Jak pobrać pliki do tłumaczenia? 9.4. Aktualizacja, przesyłanie zmian, rozwiązywanie konfliktów... 9.5. Nowy odcinek 9.6. Aktualizacja 9.7. Publikacja 9.8. Podsumowanie 10. Dodatkowe narzędzia 10.1. Dodatkowe narzędzia 10.1.1. Przeszukiwanie słownika 10.1.2. Sprawdzanie plików 10.1.3. Słownik Onet.pl 10.1.4. Generowanie dokumentów 10.1.5. Słownik dict 10.2. Wtyczki do VIMa 10.2.1. vimspell 10.2.2. po.vim 11. Domena debian.linux.org.pl 11.1. Podziękowania 11.2. Skrzynki oraz aliasy pocztowe 11.2.1. Jak otrzymać konto? 11.2.2. Jak korzystać z konta? 11.2.2.1. Klient z obsługą POP3 11.2.2.2. Interfejs WWW 11.2.3. Zmiana hasła 11.2.4. Jak odzyskać hasło? 11.2.5. Jak otrzymać alias pocztowy? 11.3. Poddomeny 12. Zakończenie 12.1. Inne informacje 12.1.1. IRC 12.1.2. Cytaty 12.2. Podsumowanie 12.3. Podziękowania 12.4. Komentarze i sugestie ------------------------------------------------------------------------------- 1. Wstęp -------- 1.1. Wprowadzenie ----------------- _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 (http://www.kernel.org) 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 (http://www.debian.org), 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_. 1.2. Dlaczego ktoś miałby Wam pomagać ? --------------------------------------- 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: * Doświadczenie: Podczas tłumaczenia/poprawiania z pewnością nauczysz się czegoś nowego. * Znajomości: 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. * Uznanie: 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. * Satysfakcja: 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. * Sława: 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. 1.3. Chcę pomóc, ale nie znam angielskiego. ------------------------------------------- _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. 1.4. Chcę pomóc, ale używam systemu Windows. -------------------------------------------- _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ć. 1.5. Chcę pomóc, ale nie wiem jak. ---------------------------------- 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 (http://debian.linux.org.pl)! ------------------------------------------------------------------------------- 2. Lista dyskusyjna ------------------- 2.1. Co to jest lista dyskusyjna? --------------------------------- 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. 2.2. Dlaczego stosujecie listę dyskusyjną? ------------------------------------------ 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. 2.3. Jak zapisać się na listę? ------------------------------ 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. 2.4. Jak włączyć się do dyskusji? --------------------------------- 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. 2.5. Netykieta -------------- 2.5.1. Odpowiadamy pod cytatem ------------------------------ 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. 2.5.2. Usuwamy zbędne cytaty ---------------------------- 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. 2.5.3. Usuwamy sygnaturki ------------------------- Sygnaturkę (podpis) osoby na której list odpowiadamy należy _bezwzględnie_ usunąć. Wyjątek stanowi komentarz odnośnie sygnaturki, ale jest to margines. 2.5.4. Zawijamy linie --------------------- 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. 2.5.5. Nie używamy formatu HTML ------------------------------- 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ć. 2.5.6. Nie wysyłamy załączników ------------------------------- 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 2.5.7. Piszemy krótko, zwięźle ------------------------------ 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. 2.5.8. Piszemy na temat ----------------------- 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ć. 2.5.9. Dane personalne ---------------------- 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. 2.5.10. Długość sygnaturki -------------------------- Przyjęło się, że sygnaturka (podpis pod listem) nie powinna przekraczać 4 linii. Przestrzegamy tej zasady. 2.5.11. Delimeter sygnaturki ---------------------------- 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. 2.5.12. Duże litery ------------------- 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*. 2.5.13. Staranność ------------------ 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. 2.5.14. Tematy wiadomości ------------------------- 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'. 2.5.15. Cytowanie ----------------- 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. 2.6. Jak rozpocząć nowy wątek? ------------------------------ Aby rozpocząć zupełnie nowy wątek dyskusji należy wysłać wiadomość na adres . Taka wiadomość automatycznie zostanie rozesłana do wszystkich zasubskrybowanych użytkowników (w tym również do Ciebie). 2.7. Archiwum. -------------- 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. 2.8. Ustawienia. ---------------- 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. 2.8.1. Jak wypisać się z listy? ------------------------------- 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ć. 2.8.2. Jak odzyskać hasło? -------------------------- 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. 2.9. Lista informacyjna ----------------------- 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. 2.10. Podsumowanie ------------------ 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. ------------------------------------------------------------------------------- 3. CVS ------ 3.1. Co to jest CVS? -------------------- 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. 3.2. Dlaczego stosujecie CVS? ----------------------------- Ż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. 3.3. Jak z tego korzystać? -------------------------- 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 . 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. 3.4. Mam konto. Co dalej? ------------------------- 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. 3.4.1. Linux ------------ 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. 3.4.1.1. Wymagane oprogramowanie -------------------------------- 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. 3.4.1.2. Pobieranie plików z repozytorium. ------------------------------------------ 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. 3.4.1.3. Aktualizacja lokalnej kopii repozytorium ------------------------------------------------- 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. 3.4.1.4. Przesyłanie poprawek ----------------------------- 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. 3.4.1.4.1. Sposób nieinteraktywny --------------------------------- 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ąć. 3.4.1.4.2. Sposób interaktywny ------------------------------ 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. 3.4.1.4.3. Edytor ----------------- 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. 3.4.1.5. Konflikty ------------------ 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: 3.4.1.5.1. Poprawki odnoszą się do różnych części dokumentu ----------------------------------------------------------- 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. 3.4.1.5.2. Poprawki nakładają się na siebie ------------------------------------------- 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. 3.4.1.6. Dodawanie pliku ------------------------ 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. 3.4.1.7. Usuwanie 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. 3.4.1.8. Zmiana nazwy 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. 3.4.1.9. Dodawanie i usuwanie katalogów --------------------------------------- _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ą. 3.4.1.10. Aktualizacja lokalnej kopii repozytorium - dodatkowe informacje. -------------------------------------------------------------------------- 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: * _U_ - plik w głównym repozytorium miał nowszą wersję niż ten, znajdujący się w naszej kopii i został zaktualizowany. Ewentualnie jest to plik, który został właśnie dodany do repozytorium przez kogoś innego i CVS pobrał go do naszej kopii. * _P_ - tak samo jak przy _U_ z tym, że przesyłane są jedynie różnice, pomiędzy plikami, a nie całość. Przez to połączenie jest mniej obciążone. * _A_ - plik został przez Ciebie dodany poleceniem `cvs add' do kolejki oczekującej na wysłanie do repozytorium. Nie został on jednak przesłany poleceniem `cvs commit' i system przypomina by to zrobić. Sposób jak to zrobić został opisany dokładniej w części Dodawanie pliku. * _R_ - plik został przez Ciebie usunięty poleceniem `cvs remove' i oczekuje, aż prześlesz o tym informacje do repozytorium za pomocą `cvs commit'. Dokładniej tę czynność opisano w części Usuwanie pliku. * _M_ - może oznaczać jeden z dwóch stanów: 1. plik w lokalnej kopii repozytorium jest zmieniony względem tego w głównym. Należy przesłać swoje poprawki do repozytorium tak jak opisano to w części Przesyłanie poprawek. 2. plik w lokalnej kopii repozytorium jest zmieniony, a w dodatku w głównym repozytorium pojawiła się jego kolejna wersja przesłana przez kogoś innego. Wtedy dodatkowo otrzymamy informację, że system połączył obie wersje w całość bez konfliktów. Należy przesłać połączoną wersję do repozytorium tak jak w 1 przypadku. * _C_ - w pliku znajduje się nierozwiązany konflikt powstały przy łączeniu różnych poprawek. Należy przyglądnąć się temu plikowi i konflikt rozwiązać tak jak opisano to w części Poprawki nakładają się na siebie. * _?_ - system CVS nie wie co to za plik. Możliwe, że jest to plik, który chciałeś dodać do repozytorium, ale tego nie zrobiłeś. 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'. 3.4.1.11. Różnice pomiędzy wersjami ----------------------------------- 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 `---'. 3.4.1.12. Skróty i synonimy --------------------------- 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: * _add_ : new * _checkout_ : co, get * _commit_ : ci * _remove_ : rm, delete * _update_ : up 3.4.1.13. Dalsze informacje --------------------------- 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 (http://www.cvshome.org). Koniecznie przeczytaj informacje ogólne o pracy z systemem CVS znajdujące się w części Informacje dodatkowe. 3.4.2. Windows -------------- 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. 3.4.2.1. Wymagane oprogramowanie -------------------------------- 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 (http://www.wincvs.org/download.html#WINCVS). Po pobraniu, rozpakowujemy archiwum na przykład korzystając z programu `Winzip' (http://www.winzip.com (http://www.winzip.com/ddchomea.htm)). 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. 3.4.2.2. Pobieranie plików z repozytorium ----------------------------------------- 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. 3.4.2.3. Domyślny edytor ------------------------ 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. 3.4.2.4. Aktualizacja lokalnej kopii repozytorium ------------------------------------------------- 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. 3.4.2.5. Przesyłanie poprawek ----------------------------- 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). 3.4.2.6. Konflikty ------------------ 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: 3.4.2.6.1. Poprawki odnoszą się do różnych części dokumentu ----------------------------------------------------------- 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. 3.4.2.6.2. Poprawki nakładają się na siebie ------------------------------------------- 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. 3.4.2.7. Dodawanie pliku ------------------------ 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. 3.4.2.8. Usuwanie 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. 3.4.2.9. Zmiana nazwy 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. 3.4.2.10. Dodawanie i usuwanie katalogów ---------------------------------------- _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ą. 3.4.2.11. Aktualizacja lokalnej kopii repozytorium - dodatkowe informacje ------------------------------------------------------------------------- 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: * _U_ - plik w głównym repozytorium miał nowszą wersję niż ten znajdujący się w naszej kopii i został zaktualizowany. Ewentualnie jest to plik, który został właśnie dodany do repozytorium przez kogoś innego i CVS pobrał go do naszej kopii. * _P_ - tak samo jak przy _U_ z tym, że przesyłane są jedynie różnice, pomiędzy plikami, a nie całość. Przez to połączenie jest mniej obciążone. * _A_ - plik został przez Ciebie dodany przy pomocy funkcji "Add selection" z menu "Modify do kolejki oczekującej na wysłanie do repozytorium. Nie został on jednak przesłany przy pomocy funkcji "Commit selection..." i system przypomina by to zrobić. Sposób jak to zrobić został opisany dokładniej w części Dodawanie pliku. * _R_ - plik został przez Ciebie usunięty przy pomocy funkcji "Remove selection" z menu "Modify" i oczekuje, aż prześlesz o tym informacje do repozytorium za pomocą funkcji "Commit selection...". Dokładniej tę czynność opisano w części Usuwanie pliku. * _M_ - może oznaczać jeden z dwóch stanów: 1. plik w lokalnej kopii repozytorium jest zmieniony względem tego w głównym. Należy przesłać swoje poprawki do repozytorium tak jak opisano to w części Przesyłanie poprawek. 2. plik w lokalnej kopii repozytorium jest zmieniony, a w dodatku w głównym repozytorium pojawiła się jego kolejna wersja przesłana przez kogoś innego. Wtedy dodatkowo otrzymamy informację, że system połączył obie wersje w całość bez konfliktów. Należy przesłać połączoną wersję do repozytorium tak jak w 1 przypadku. * _C_ - w pliku znajduje się nierozwiązany konflikt powstały przy łączeniu różnych poprawek. Należy przyglądnąć się temu plikowi i konflikt rozwiązać tak jak opisano to w części Poprawki nakładają się na siebie. * _?_ - system CVS nie wie co to za plik. Możliwe, że jest to plik, który chciałeś dodać do repozytorium, ale tego nie zrobiłeś. 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". 3.4.2.12. Różnice pomiędzy wersjami ----------------------------------- 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 `---'. 3.4.2.13. Klawisze skrótów -------------------------- 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: * _Przesyłanie_ : CTRL M * _Aktualizacja_ : CTRL U * _Różnice_ : ALT = 3.4.2.14. Dalsze informacje --------------------------- 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 (http://www.cvshome.org). Koniecznie przeczytaj informacje ogólne o pracy z systemem CVS znajdujące się w części Informacje dodatkowe (#s-dodatkowe). 3.5. Informacje dodatkowe ------------------------- To już prawie wszystko co powinieneś wiedzieć o korzystaniu z systemu CVS. Poniżej jeszcze tylko kilka uwag odnośnie pracy. 3.5.1. Częste aktualizacje -------------------------- 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. 3.5.2. Wersjonowanie plikó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. 3.5.3. Informuj co robisz ------------------------- 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. 3.5.4. Kto pyta, nie błądzi --------------------------- 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. 3.5.5. Commit ------------- 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. 3.6. Dostęp do CVS przez stronę WWW ----------------------------------- Istnieje możliwość przeglądania repozytorium poprzez strony WWW. 3.6.1. ViewCVS -------------- 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. 3.6.2. CVS Monitor ------------------ 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. ------------------------------------------------------------------------------- 4. Edytory ---------- 4.1. Dlaczego taki rozdział? ---------------------------- 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. 4.2. Linux ---------- 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ć. * _Vim_ - jeden z niekwestionowanych liderów wśród edytorów dostępnych pod systemem Linux (jest również wersja pod Windows). Koloruje składnię praktycznie wszystkich znanych formatów na świecie i pozwala "oskryptować" każdą czynność. Dla początkujących trudny w obsłudze, zaawansowani użytkownicy nie wyobrażają sobie pracy bez niego. Szczególne zalety można docenić podczas pracy zdalnej. 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'. * _Emacs_ - drugi najpopularniejszy edytor dostępny pod systemem Linux. Pomiędzy nim i `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. * _mcedit_ - edytor dostępny wraz z menedżerem plików `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. * _jed_ - kolejny popularny edytor. Zupełnie inna klawiszologia od poprzednich, jednakże dla niektórych jest ona wygodniejsza. Pozostaje po prostu spróbować i samemu ocenić. 4.3. Windows ------------ 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: * Używanie edytora tekstu, który potrafi odczytywać/zapisywać pliki w takim standardzie. * Instalacja specjalnego sterownika klawiatury oraz czcionek obsługujących ten standard. * Konwertowanie plików przed i po edycji z i na ten standard. 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. 4.3.1. Pobieranie i instalacja ------------------------------ 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'. 4.3.2. Konfiguracja ------------------- 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. 4.4. Informacje ogólne ---------------------- 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. ------------------------------------------------------------------------------- 5. DebianDoc ------------ 5.1. Co to jest DebianDoc? -------------------------- 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. 5.2. Dlaczego używacie DebianDoc? --------------------------------- Ponieważ pliki zapisane w tym języku są zwykłymi plikami tekstowymi zawierającymi jedynie specjalne znaczniki typu lub . 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. 5.3. Jak wygląda DebianDoc? --------------------------- Oto przykładowy plik: Instrukcja gaszenia światła Bartosz Feński aka fEnIo fenio@debian.org v0.2 Copyright (C) 2003-2006 Bartosz Feński aka fEnIo

Instrukcja powstała by zaprezentować możliwości formatu DebianDoc. Żadnych gwarancji nie uwzględnia się. Używaj na własną odpowiedzialność. Wstęp Wprowadzenie

W instrukcji opisane zostaną sposoby na zgaszenie światła. Gaszenie światła

Są trzy podstawowe sposoby gaszenia światła: Przełączenie kontaktu Wykręcenie żarówki Wykręcenie stopek Ostrzeżenie

Uważaj by nie poraził Cię prąd. 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: , oraz zamykającej: 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: xlib6 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 oraz 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. 5.4. Znaczniki dostępne w DebianDoc ----------------------------------- Wszystkie znaczniki posiadają swój odpowiednik zamykający, chyba, że zaznaczono inaczej. Poniżej lista wraz z krótkim opisem: * __ - określa format dokumentu. Musi zawsze znajdować się w pierwszej linii. * __ - tytuł dokumentu * _<author>_ - autor dokumentu * _<name>_ - imię i nazwisko autora. Musi znajdować się wewnątrz znacznika <autor> * _<email>_ - adres poczty elektronicznej autora. Może również występować w dalszych częściach dokumentu * _<version>_ - wersja dokumentu * _<date>_ - data utworzenia wstawiana automatycznie. Nie występuje znacznik kończący. * _<abstract>_ - streszczenie dokumentu. Maksymalnie jeden paragraf. * _<copyright>_ - informacje o prawach autorskich * _<p>_ - paragraf * _<toc>_ - spis treści. Zawiera dodatkowy atrybut określający jak dokładny ma być spis. * _<chapt>_ - rozdział * _<sect>-<sect4>_ - podrozdziały. Im większa cyfra, tym mniej istotny podrozdział. * _<appendix>_ - dodatek * _<em>_ - wyróżniony tekst * _<strong>_ - bardziej wyróżniony tekst * _<var>_ - kursywa * _<package>_ - nazwa pakietu * _<prgn>_ - nazwa programu * _<file>_ - plik lub katalog * _<tt>_ - polecenia lub ich wyniki * _<qref>_ - ciche odwołanie * _<ref>_ - odwołanie * _<manpage>_ - odwołanie do podręcznika systemowego * _<ftpsite>_ - adres serwera FTP * _<ftppath>_ - ścieżka na serwerze FTP * _<httpsite>_ - adres serwera WWW * _<httppath>_ - ścieżka na serwerze WWW * _<url>_ - odwołanie do zewnętrznych dokumentów * _<footnote>_ - przypis * _<list>_ - lista * _<enumlist>_ - lista numerowana * _<taglist>_ - lista z oznaczonymi elementami * _<item>_ - element listy * _<example>_ - przykład 5.5. Znaki specjalne -------------------- 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: * _<_ - < * _>_ - > * _&_ - & * _(C)_ - © * _(R)_ - ® * _(TM)_ - ™ 5.6. Generowanie plików wynikowych ---------------------------------- Z formatu DebianDoc można bez problemu uzyskać następujące pliki wynikowe: * HTML * PDF * PS * TXT 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. 5.7. Podsumowanie ----------------- 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. ------------------------------------------------------------------------------- 6. Praca -------- 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ń. 6.1. Zanim zaczniesz -------------------- 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: * _HTML_ - tworzenie stron WWW, zalicza się tu również znajomość styli CSS itp. * _SGML_ - znajomość formatu SGML, a w szczególności DebianDoc * _[X]SQL_ - wszelkiego rodzaju relacyjne bazy danych oparte na SQL * _PHP_ - język programowania PHP * _CVS_ - umiejętność posługiwania się CVS * _Grafika_ - zdolności graficzne [komputerowe ;)] * _Angielski_ - chyba nie wymaga tłumaczenia * _Inne_ - wszelakie inne umiejętności, które mogą być przydatne w projekcie [np. Perl, C/C++, dostęp do taniego browaru, ładna siostra do wyswatania ;)] 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". 6.2. Co dalej? -------------- 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. 6.3. Jak tłumaczyć? ------------------- 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: * Słownik ..:: Onet ::.. http://slowniki.onet.pl * Słownik ..:: Translate.pl ::.. http://translate.pl/ * Słownik informatyczny ..:: Marcin Miłkowski ::.. http://venus.ci.uw.edu.pl/~milek/slow.htm * Słownik terminologii internetowej ..:: Grzegorz Grudziński & Aleksy Schubert ::.. http://zls.mimuw.edu.pl/~alx/slownik/slownik.html * Słownik terminologii związanej z bezpieczeństwem sieci ..:: Robert Maron ::.. http://zls.mimuw.edu.pl/~robmar/slownik.html * dictionary.plukwa.net http://dictionary.plukwa.net * Słownik angielsko-angielski ..:: Dictionary.com ::.. http://dictionary.reference.com/ * Słownik angielsko-angielski terminologii sieciowej i uniksowej ..:: Kevin Kadow ::.. http://www.msg.net/kadow/answers/ W części Dodatkowe narzędzia opisane są skrypty i programy, które również mogą być przydatne przy tłumaczeniu. Odsyłacze do wymienionych słowników dostępne są również w Kąciku deweloperów (http://debian.linux.org.pl/dev/). 6.4. Dzień po dniu... --------------------- W tej części opisane są sytuacje, które możesz napotkać podczas codziennej pracy oraz tok postępowania w przypadku ich zaistnienia 6.4.1. Nie wiem jak przetłumaczyć --------------------------------- Z pewnością kiedyś zdarzy się, że natrafisz na wyraz lub zwrot, którego nie potrafisz przetłumaczyć, albo tłumaczenie brzmi niezręcznie, a nawet dziwnie. A w dodatku nie ma nic na ten temat w naszym wewnętrznym słowniku. Co w takim przypadku? Rozwiązanie jest proste jak udo przed złamaniem. Należy przesłać taki zwrot lub wyraz na listę dyskusyjną z prośbą o pomoc. W końcu co 30 głów to nie jedna. Warto jednakże pamiętać, żeby posyłać problematyczne zwroty wraz z kontekstem. Najlepiej z poprzedzającym i następnym zdaniem. To bardzo ułatwia pomoc. Nie każdy ma czas by doszukiwać się w którym pliku i w jakim jego miejscu występuje ta fraza, a mając kontekst można już z dużym prawdopodobieństwem dokonać odpowiedniego tłumaczenia. Istnieje możliwość, że w wyniku rozmowy, którą zapoczątkujesz, wyraz, który okazał się problematyczny trafi do naszego wewnętrznego słownika. Tak, że nie krępuj się i pisz na listę ze wszystkimi wątpliwościami. 6.4.2. Znaczniki DebianDoc -------------------------- Format dokumentów najczęściej przez nas stosowany został opisany w rozdziale DebianDoc. Jednakże jest to opis ogólny i ma za zadanie jedynie wprowadzić czytającego w to zagadnienie. Nie wyjaśnia on jednak, wielu sytuacji, które moga przytrafić się podczas tłumaczenia. Ogólnie rzecz ujmując nigdy nie tłumaczymy tego co znajduje się wewnątrz znaczników < i >. Istnieją jednak od tej reguły pewne wyjątki. I o nich sobie teraz powiemy. 6.4.2.1. "Entitki" ------------------ Czasem w dokumentach możemy natrafić na tak zwaną "entitkę". Oto przykład takiego zdania: Debian includes more than &all-pkgs; software packages at present. Widać, że &all-pkgs; wygląda dość dziwnie na tle zwykłych wyrazów. To właśnie owa "entitka". Najpierw może postaram się wyjaśnić co to takiego. Jeśli ktoś kiedykolwiek zajmował się programowaniem to najlepiej będzie mu zrozumieć to poprzez analogię do stałej, którą definiujemy sobie w programie. Definicja takiej stałej najczęściej znajduje się na początku programu, a później już możemy odwoływać się do niej poprzez nadaną nazwę. Jest to szczególnie przydatne jeśli dana stała jest wykorzystywana w programie wiele razy. Bo jeśli nagle przy prawie skończonym programie okazałoby się, że zaistniała potrzeba zmiany jednego parametru, to wystarczy zmienić go na początku programu, a jako, że w dalszej części odwołujemy się do tej stałej, to automatycznie mamy poprawiony cały program. Dla tych co nie programowali wyjaśnię to na przykładzie. Załóżmy, że mamy plik w formacie SGML o takiej treści (to oczywiście duże uproszczenie): <!entity nazwa "PDDP"> Witamy w projekcie &nazwa; ! Zapytasz pewnie dlaczego nasz projekt nazywa się &nazwa;? Otóż &nazwa; oznacza Polish Debian Documentation Project. Teraz zapewne bez trudu rozumiesz dlaczego projekt nazywa się &nazwa;. z poważaniem koordynator &nazwa; W pierwszej linii następuje definicja "entitki". Od tej pory każde użycie &nazwa; zostanie podczas generowania dokumentu zastąpione tym co zadeklarowaliśmy, czyli w naszym przypadku "PDDP". Dlatego właśnie "entitki" nie uświadczysz w wynikowym pliku takim jak PDF, HTML czy TXT. Powyższy przykład po przetworzeniu na plik TXT wyglądałby tak: Witamy w projekcie PDDP ! Zapytasz pewnie dlaczego nasz projekt nazywa się PDDP? Otóż PDDP oznacza Polish Debian Documentation Project. Teraz zapewne bez trudu rozumiesz dlaczego projekt nazywa się PDDP;. z poważaniem koordynator PDDP Jak widać każde wystąpienie &nazwa; zostało zastąpione poprzez PDDP. No i dochodzimy do sedna sprawy. Teraz jak na dłoni widać zastosowanie "entitek". Spójrz jak łatwo zmieniając definicję w pierwszej linii zmieniasz treść wszystkich następnych. Załóżmy, że w pierwszej linii zmieniamy "PDDP" na "xxx". Wynikowy plik przyjmie postać: Witamy w projekcie xxx ! Zapytasz pewnie dlaczego nasz projekt nazywa się xxx? Otóż xxx oznacza Polish Debian Documentation Project. Teraz zapewne bez trudu rozumiesz dlaczego projekt nazywa się xxx;. z poważaniem koordynator xxx To chyba wystarczające wyjaśnienie zasady działania "entitek". No dobra, ale tłumacząc dokument najczęściej nie widać nigdzie deklaracji tych "entitek". No więc gdzie są? Ano najczęściej w osobnym pliku, który uwzględniany jest przy generowaniu dokumentów wynikowych. Nosi on zazwyczaj nazwę `default.ent' lub `custom.ent', ale nie jest to regułą. Trzeba go po prostu poszukać. Trzeba to nawet mało powiedziane. Musisz go znaleźć, gdyż bez tego nie znasz znaczenia "entitki" i jest duże prawdopodobieństwo, że źle przetłumaczysz zdanie. Wróćmy do naszego pierwszego przykładu. Debian includes more than &all-pkgs; software packages at present. Występuje tutaj "entitka" o nazwie &all-pkgs;. Szukamy więc jej znaczenia. W tym wypadku jej deklaracja wygląda następująco: <!entity all-pkgs "8250"> Czyli &all-pkgs; zostanie zastąpione liczbą 8250. Wiedząc to przystępujemy do tłumaczenia i zapewne wyjdzie nam coś na wzór: W chwili obecnej Debian zawiera więcej niż &all-pkgs; pakietów. Teoretycznie wszystko jest OK, bo po wygenerowaniu pliku wynikowego otrzymamy: W chwili obecnej Debian zawiera więcej niż 8250 pakietów. Wygląda super, ale jest to _bardzo złe_ zastosowanie "entitki". Dlaczego? Ano spójrzmy co się stanie gdy ktoś za parę miesięcy zaktualizuje cały dokument i w deklaracji "entitki" zmieni liczbę 8250 na przykładowo 8332. Popatrzmy co wyjdzie po wygenerowaniu: W chwili obecnej Debian zawiera więcej niż 8332 pakietów. Mamy ewidentnie źle złożone zdanie. Uczulam na ten fakt. Zwłaszcza gdy "entitka" wskazuje na liczbę. W języku polskim różnie zapisuje się rzeczownik w połączeniu z liczebnikiem (jeden - chleb, dwa - chleby, pięć chlebów). W języku angielskim nie mają takich zmartwień. Jak zatem poradzić sobie z tym problemem? Na szczęście język jest na tyle elastyczny, że zdanie można tak przebudować by liczebnik nie miał wpływu na resztę zdania. Oto przykład: &all-pkgs; lub więcej, to aktualna liczba pakietów w Debianie Jak widać problem z głowy. Teraz jakakolwiek zmiana "entitki" nie zepsuje nam zdania. Oczywiście może się zdarzyć, że przebudowanie zdania nie będzie możliwe, albo po przebudowaniu zdanie będzie brzmieć co najmniej nienaturalnie. Co wtedy? Wtedy po prostu usuwamy "entitkę" a w jej miejsce wprowadzamy to na co zostałaby zastąpiona. Należy jednak robić to tylko w nieuniknionych sytuacjach, gdyż bardzo ciężko potem znaleźć takie zmiany podczas aktualizacji. Najlepiej gdy masz wątpliwości po prostu zapytaj na liście dyskusyjnej. 6.4.2.2. Odsyłacze ------------------ Kolejnym wyjątkiem od reguły, że nie zmieniamy znaczników DebianDoc, są odsyłacze. Tradycyjnie przykład: For additional information about this, please see our web page about <url name="reasons to choose Debian" id="http://www.debian.org/intro/why_debian">. Istotne w tym przykładzie jest to co znajduje się wewnątrz znacznika <url>, a szczególnie atrybut `name', bo on zostanie w wynikowym pliku. Oto przykład po wygenerowaniu: For additional information about this, please see our web page about reasons to choose Debian. Jak widać mimo iż słowa `reasons to choose Debian' znajdowały się wewnątrz znacznika to znalazły się w wynikowym pliku. Należy na to zwracać uwagę i w tym wypadku przetłumaczyć to co znajduje się przy `name' na `powody wyboru Debiana'. 6.5. Tydzień po tygodniu... --------------------------- W tym podrozdziale zajmiemy się sytuacjami, które zdarzają się rzadziej, ale są również bardzo istotne. 6.5.1. Aktualizacja tłumaczeń ----------------------------- Z racji tego, że większość dokumentów, które tłumaczymy, jest cały czas rozwijana, istnieje potrzeba aktualizacji tłumaczeń. Nie wystarczy raz przetłumaczyć dokumentu (czy jego części) i o nim zapomnieć. Co jakiś czas w głównym repozytorium będą pojawiać się nowe wersje oryginału, a wtedy należy przejrzeć jakie zmiany w nim zaszły i ewentualnie nanieść poprawki na polski odpowiednik. W tym podrozdziale opiszę jak najlepiej dokonywać takich aktualizacji. Odpowiednio dobrane narzędzia potrafią w tym względzie znacznie zminimalizować ilość potrzebnego czasu. Najlepiej przedstawię wszystko na przykładzie. To chyba najlepszy sposób nauki. Załóżmy, że grupa skupia się w danym momencie na tłumaczeniu dokumentu _Quick Reference_. W związku z tym w repozytorium w katalogu `manuals.sgml' pojawia się podkatalog `quick-reference/'. Wewnątrz tego podkatalogu tworzone są dwa kolejne. `en/' z angielską wersją oraz `pl/' z naszymi tłumaczeniami. Na początku oczywiście zawartość obydwóch podkatalogów jest taka sama. Z biegiem czasu w podkatalogu `pl/' zaczynają pojawiać się pierwsze efekty pracy grupy. Teksty angielskie są zastępowane przez polskie.