Rozwój systemu/Pakiety/Repozytorium

Z Mandriva Poland

Repozytorium systemu
Strona w trakcie korekty językowej!
Trwa korekta językowa tej strony. Strona może ona zawierać błędy.

Po dokonaniu korekty proszę usunąć kategorię - strona do korekty.

Repozytorium zarządzania pakietami oparte na subversion

Nowy system repozytorium oparty jest na oryginalnej budowie pakietów i testowania systemu Conectiva. Aktualny status repozytorium Mandrivy jest PRZEJŚCIOWY. Wiele pakietów znajduje się już w repozytorium oraz dostosowane są narzędzia budowy.

Spis treści


Repozytorium oprogramowania

Repozytorium systemu opiera się o Subversion. Po wielu różnych pomysłach, Subversion ma rozwiązać wiele problemów, które chcieliśmy ustalić w poprzedniej realizacji. Ten dokument wyjaśni, w jaki sposób jest zorganizowane drzewo repozytorium.

Quickstart

Proszę zobaczyć Development/Packaging/RepositorySystem/Quickstart na przykład, w jaki sposób pracować z pakietami przechowywanymi w SVN. Przykład ten pokazuje sposób ralizacji pakietów, zmień je, dokonaj zmiany i zwróć do repozytorium.

Pojęcia Subversion

Proste kopie

Subversion wykorzystuje metodę o nazwie bubble-up ulepszoną wersję pliku drzew. Nie będie tu wyjaśnione co to dokładnie znaczy, ponieważ to wystarczy dla naszego wyjaśnienia, że to włącza kopiowanie całego pliku drzew na bardzo prostej operacji. Kiedy zobaczysz, że wspomniane drzewo ma być gdzieś klonowane, nie martw się.

Struktura repozytorium

Ta sekcja wyjaśnia w jaki sposób jest zorganizowane repozytorium. Wprowadzi pewne pojęcia i będziesz miał z nimi styczność.

Drzewo repozytorium

Oto przykład jak wygląda drzewo repozytorium. Zastosowano niedomówienia, kiedy dodatkowe informacje nic nie wyjaśniają.

  • cooker/ (1)
    • pkgname/ (2)
      • current/
        • SPECS/
          • pkgname.spec
        • SOURCES/
          • pkgname-2.3.tar.bz2 (3)
          • pkgname-foo.patch
      • pristine/
        • SPECS/
          • pkgname.spec
        • SOURCES/
          • pkgname-2.1.tar.bz2 (4)
      • releases/
        • 1:2.0/
          • 1cl/
            • SPECS/
              • pkgname.spec
            • SOURCES/
              • pkgname-2.0.tar.bz2
              • pkgname-foo.patch
          • 2cl/
            • SPECS/
              • pkgname.spec
            • SOURCES/
              • pkgname-2.0.tar.bz2
              • pkgname-foo.patch
        • 1:2.1/
          • 1cl/
            • SPECS/
              • pkgname.spec
            • SOURCES/
              • pkgname-2.1.tar.bz2
              • pkgname-foo.patch
      • branches/
        • 1:3.0beta/
          • pkgname
            • current
            • pristine
            • releases
  • releases/ (5)
    • 2005/
      • pkgname/
        • current/
          • ...
        • releases/
          • ...
        • pristine/
          • ...
        • branches/
          • ...
  • updates/ (6)
    • 2005/ (7)
      • pkgname/ (8)
        • current/
          • SPECS/
            • pkgname.spec
          • SOURCES/
            • pkgname-2.0.tar.bz2
            • pkgname-foo.patch
        • pristine/
          • SPECS/
            • ...
          • SOURCES/
            • ...
        • releases/
          • 1:2.0/
            • 1cl/
              • SPECS/
                • ...
              • SOURCES/
                • ...
        • branches/
          • ...
  • branches/ (9)
    • pkgname-threaded/
      • pkgname/
        • current/
          • SPECS/
            • pkgname.spec
          • SOURCES/
            • pkgname-2.0.tar.bz2
            • pkgname-foo.patch
        • releases/
          • ...
          • ...
  • tags/ (10)
    • bootstrap/
      • pkgname/
        • current/
          • ...
        • releases/
          • ...
    • pristine/
      • ...
  • misc/ (11)
    • pkgname/
      • log (12)
      • ...

Zmienne miejsca

Większość katalogów nie jest zmieniana w repozytorium systemu. Te obiekty, które mają być zmienione zostały oznaczone pogrubioną trzcionką w powyższym drzewie repozytorium. W pozostałej części tego dokumentu można znaleźć, w jaki sposób i kiedy one powinny być zmieniane.

Katalog Cooker

To w katalogu cooker/ (1) występuje większość rozwojowych pakietów. Tutaj pakiety rozpoczynają swój żywot w repozytorium, tu zostaje wprowadzanych większość zmian w ciągu ich całego życia. Wewnątrz tego katalogu dla każdego pakietu jest jeden katalog (2), który jest częścią systemu Mandriva Linux Cooker. Katalogi te zawsze muszą pasować do aktualnej nazwy pakietu. Oznacza to, że jak tylko zmiana nazwy pakietu jest zatwierdzona a plik spec jest edytowany, należy zmienić nazwę tego katalogu (jest to jedyny powód, dla którego katalog ten jest zmienny).

Struktura katalogu pliku

Wewnątrz każdego pakietu katalogu (2) znajdują się trzy katalogi:

  • current/: Ten katalog zawsze posiada najnowsze zmiany pakietu. Tutaj znajdziesz część struktury RPM %_topdir, z podkatalogami SPECS/ i SOURCES/. Informacje, które one przetrzymują pasują z oczekiwaniami wspólnego pakietu SRPM. Tam właśnie zmiany w tym pakiecie zostaną wprowadzone.
  • releases/: W tym katalogu znajdziesz proste kopie katalogu current/. Kopie wykonane na ten moment w miarę dokładnie, tak że określone pakiety zostały wydane dla użytkowników cooker. Zmiany nie są tutaj dozwolone. Te katalogi i pliki są tylko informacyjne i są utworzone przez automatyczny system.
  • pristine/: Ten katalog posiada aktualny stan katalogu current/ kiedy ostatni pakiet został zwolniony dla użytkowników cooker. Przydaje się to, żeby wiedzieć, co zostało zmienione w pakiecie current/ od ostatniego wydania. Podobnie jak katalog release/ zmiany nie są dozwolone, ponieważ jest to tworzone przez automatyczny system.
  • branches/: Czasami chcemy mieć dwie główne wersje pakietu w dystrybucji. Zazwyczaj wyżej ponumerowana jest wersja beta albo jakiś eksperymentalny. Czasami po prostu chcemy zaoferować dwie główne wersje stabilne (np. postfix 2.2 i postfix 2.3). W tych przypadkach możemy używać pakietu katalogu branches/. Każdy pakiet wewnątrz niego ponownie będzie aktualny, wydany i dawne drzewo (oczywiście nie oddziały).

W powyższym przykładzie można zaobserwować, patrząc na (3) i (4), że aktualnie katalog posiada zmiany, które nie zostały jeszcze dopuszczone do publikacji (zauważ, że zmiany nie zawsze są tak oczywiste ale Subversion zapewnia zasoby, by łatwo wykryć to co się zmieniło).

Katalog releases

Katalog releases/ (5) posiada pełny obraz katalogu cooker/ (1) ilekroć Mandriva Linux zostanie wdana. Należy przez to rozumieć odniesienie i żadne zmiany w nim nie są dozwolone.

Katalog updates

Po pierwsze, katalog updates/ (6) wygląda dokładnie tak jak katalog releases/ (5). Faktycznie, oba posiadają podobną strukturę a ich pierwszy poziom podkatalogów (7) jest zawsze tworzony w tym samym czasie. Fundamentalana różnica m.in. polega na tym, że katalog updates/ jest zmienny, to oznacza posiadanie zmian w systemie Mandriva Linux po jego wydaniu. Czasami potrzebne są ważne zmiany więcej niż jednego wydania Mandriva Linux i/lub pakietów cooker. W takim przypadku należy zmienić pakiet we wszystkich miejscach, tj. wszystkie podkatalogi updates/ (6) korespondują z dystrybucją i/lub katalogiem cooker/ (1). Jeśli chcesz możesz użyć funkcji korespondencji seryjnej w Subversion, które pomogą w tym zadaniu. Zauważ, że pakiet katalogów (8) nie jest tutaj zmienny, ponieważ w odróżnieniu od cooker/ nie są one oznakowane do przemiany.

Oddziały katalogu

Czasami, możesz chcieć zmienić jeden lub więcej pakietów w cooker bez naruszania pracy innych pakerów. Właśnie tam katalog branches/ (9) jest użyty. Jako pierwszy poziom podkatalogi są kopiami całego katalogu cooker/, nawet jeśli tylko jeden pakiet jest zmieniany. Istnieją ważne powody by tak zrobić:

  • kopiowanie całego katalogu cooker/ jest jak proste kopiowanie tego;
  • jeśli później odkryjesz, że zmiany w innych pakietach są konieczne, one juz tam są;
  • za darmo otrzymasz informacje, w jaki sposób cooker w danej chwili jest rozwijany;
  • to jest bardziej spójne.

Zauważ, że jeśli chcesz wprowadzić zmiany w innych pakietach w sposób wyjaśniony wyżej, oddziały/ nie są miejscem do wprowadzenia nowych pakietów. Zwykle powinny być kierowane bezpośrenio do katalogu cooker/.

Okres życia katalogu wewnątrz oddziału/ nie jest pewny, pakowacze po ich użyciu decydują, które mają być usunięte i że nie potrzebują ich więcej.

UWAGA: Gdy skończysz, nie kopiuj oddziału rozwoju w cookerze! Zawsze swoją pracę połącz z powrotem w cookerze, porównując to co zmieniło się od czasu odłamu do tego co jest aktualne. Gubienie zmian wprowadzonych przez innych jest niedopuszczalne.

Katalog tagów

Ten katalog jest podobny do katalogu releases/ (5) ale posiada więcej bardziej ogólne kopie tagów z katalogu cooker/. Jest używany do oznaczenia stanu katalogu cooker/ w danym momencie, które wydarzyły się między wydaniami Mandriva Linux.

Katalog Misc

Katalog misc/ (11) posiada różne informacje na temat każdego pakietu. Teraz informacje przechowywane są w tym katalogu, jest starym changelog każdego nazwanego pakietu wewnątrz pliku o nazwie "log" (12). Ten plik, jeśli jest, musi zawierać rpm changelog bez tagu _%changelog_ .

Wskazówki

  • Zrozum te pojęcia! Są one niezbędne jeśli chcesz pracować z repozytorium systemu.
  • Nie jest konieczne wysyłanie pakietu do cookera za każdym razem, gdy coś zmienisz w repozytorium. Możesz dać odpocząć "etapowi" twojej zmiany, zapewnimamy, że użytkownik kontrolujący pakiet dostanie ją następnym razem.
  • Bądź ostrożny kiedy ponownie łączysz zmiany w oddziałach katalogu. Możesz się zdziwić jeśli nadpiszesz zmiany dokonane przez innych.

Wiadomości changelog

Pisanie dziennika wiadomości

Przed wprowadzeniem podstawowych operacji w repozytorium, należy ustalić pewne konwencje dotyczące zmian wiadomości. Pamiętaj, że wiadomości te wykorzystywane są w sekcji wytwarzania RPM %changelog, więc format ma znaczenie. Po pierwsze, należy opisać jakąkolwiek zmianę w pakiecie, korzystanie z kapitału oraz używać poprawnej interpunkcji. Poza tym używanie do generowania sekcji %changelog dziennika jest najlepszym dokumentem jaki mamy dla pakietów. Jeśli zamierzasz napisać pojedyńczy wpis, śmiało wpisz go normalnie: 

This is a changelog entry, which could have one 
or more lines.

Jeśli dziennik ma więcej niż jeden wpis, użyj kreski do oddzielenia ich w stylu RPM %changelog: 

- This is a changelog entry which 
  is very long. 
- And I also have a second entry.

"CICHE" widomości changelog

Możesz ukryć dziennik wiadomości Subversion w granicach pakietu %changelog używając SILENT (wszystkie przyciski) jako słowa kluczowego. Zasady są następujące:

  • "SILENT" jako pierwsze słowo w pierwszej linii w dzienniku Subversion będzie tłumić wszystkie wiadomości w generowanym pakiecie %changelog
  • inaczej,"SILENT" w dowolnym miejscu w linii ukrywa tylko linię generowanego pakietu %changelog

Tłumienie całej wiadomości: 

SILENT
This whole message will be suppressed.

You can even do ASCII art here.

Tłumienie pojedyńczej linii (w tym przykładzie tylko pierwsza linia będzie wyświetlana w %changelog): 

- upgraded to version x.y.z
- SILENT: cleanup whitespace in the spec file
- renamed patch to fix typo (SILENT: not relevant for %changelog)
- nothing to see here, move along (SILENT)

Ustalanie błędnych wpisów

Jeśli zrobiłeś jakiś błąd w wpisie, wiedz, że można użyć następującego polecenia: 

svn pedit svn:log --revprop -r <revision> svn+ssh://repos

Usuwanie starych sesji %changelog

Edytując kiedykolwiek plik spec w repozytorium i zauważyłeś, że nadal ma sesję _%changelog_, proszę o szlak (w tym sam tag %changelog). Stare pozycje changelog dostępne przed wdrożeniem systememu repozytorium będą bezpieczne w starych korektach i mogą być łatwo dostępne w podkatalogach tagi/ i releases/.

Zapisywanie starych sesji %changelog

Jeśli chcesz zachować stare sesje pakietów %changelog, które masz w repozytorium, mozesz to zrobić zapisując je w pliku o nazwie /misc/pkgname/log. Ten plik zostanie dołączony do zmian pochodzących repozytorium logów. Zobacz niżej aby uzyskać więcej informacji na ten temat.

Rada

  • Zapisz zmiany! Nikt nigdy nie będzie się skarżył jeśli wyjaśnisz co robisz i ludzie (w tym i ty) dowiedzą się szybko o problemach.

Repozytorium operacji

Tutaj jest opisana procedura o niektórych zwykłych operacjach w repozytorium systemu.

Repozytorium lokalizacji

Po zrozumieniu powyższych pojęć jesteś gotowy aby sprawdzić rzeczywiste repozytorium. Znajduje się pod następującym adresem URL:

Dobra wizualizacja i porównanie w internecie, wykorzystaj: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/

Subversion stanowi podstawowy dostęp poprzez przeglądarkę, tak aby można było poruszać się w tym adresie URL. Wybór dostępu do subversion Mandrivy to svn+ssh.

UWAGA: W poniższych przykładach, z korzyścią dla zwięzłości, URL svn+ssh://<repos> będzie stosowany zamiast rzeczywistego,przedstawionego powyżej.

Zmiana pakietu

Gdy chcesz zmienić pakiet należy wykonać następujące kroki:

Pobierz moduł do pracy i skopiuj do katalogu /path/pkgname, np.: 

svn checkout svn+ssh://<repos>/cooker/pkgname/current /path/pkgname

Będzie to podstawowa struktura z katalogami SPECS/ i SOURCES/. Zmiana pakietu spec i/lub usunięcie, dodanie, przenoszenie plików w SOURCES/, np.: 

# Add new version (dodaj nową wersję)
cp pkgname-1.2.tar.bz2 /path/pkgname/SOURCES 
svn add /path/pkgname/SOURCES/pkgname-1.2.tar.bz2 
 
# Remove old one (usuń stare)
svn rm /path/pkgname/SOURCES/pkgname-1.1.tar.bz2 
 
# Move patch (przenieś)
svn mv /path/pkgname/SOURCES/pkgname-1.1-foo.patch /path/pkgname/SOURCES/pkgname-1.2-foo.patch

UWAGA: Pamiętaj aby dodać używane polecenia svn /rm/cp/mv jeśli dodajesz, usuwasz, przenosisz lub kopiujesz plik wewnątrz repozytorium (nie kiedy edytujesz). Teraz przetestuj pakiet wykorzystując jedną z procedur wyjaśnioną poniżej. Po zakończeniu wyślij swoje zmiany: 

svn commit /path/pkgname

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian.

UWAGA: Jeśli zamierzasz tylko zmienić plik spec, prawdopodobnie będziesz potrzebował tylko katalog SPECS/ zamiast całego katalogu current/.

Testowanie pakietu

Za każdym razem kiedy dokonujesz zmiany pakietu, możesz przetestować zmiany w budowie pakietu. Jest to dość łatwo zrobić. Oto kilka różnych technik, by osiągnąć takie same wyniki.

Korzystanie z BuildManager

Najprostszym spsobem przetestowania pakietu jest użycie bm. Oprócz innych funkcji, narzędzie to ułatwia pracę z RPM, które są poza wstępnym %_topdir. Korzystanie z niego jest zupełnie proste. Jeśli gdzieś wewnątrz pakietu %_topdir: 

bm

jeśli poza _%_topdir_: 

bm /path/pkgname

Możesz także ręcznie określić, które pliki spec budować ręcznie: 

bm /path/pkgname/SPECS/pkgname.spec

Używanie tylko rpm

Możesz użyć tylko zwykłego pakietu rpm. Jeśli tak, wykonaj poniższe proste czynności. Tworzenie brakujących katalogów: 

mkdir -p /path/pkgname/{RPMS,SRPMS,BUILD}

I budowa pakietu, ustawienie zmiennej RPM_%_topdir_ : 

rpm -ba --define "_topdir /path/pkgname" /path/pkgname/SPECS/pkgname.spec

Zmiana nazwy pakietu

Jeśli jesteś pewny, że chcesz dokonać zmiany pakietu, wykonaj następujące kroki:

Przesuń pakiety katalogu cooker i podkatalog misc/, jeśli istnieje. Zauważ, że te operacje są wykonywane całkowicie w repozytorium, więc nie masz szans na błędy: 

 
svn mv svn+ssh://<repos>/cooker/oldname svn+ssh://<repos>/cooker/newname 

svn mv svn+ssh://<repos>/misc/oldname svn+ssh://<repos>/misc/newname

Pobrany moduł do pracy skopiuj do katalogu: 

svn checkout svn+ssh://<repos>/cooker/newname/current /path/newname

Edytuj plik spec aby zmienić nazwę pakietu i również go przenieść: 

svn mv /path/newname/SPECS/oldname.spec /path/newname/SPECS/newname.spec

Po zakończeniu prześlij zmiany: 

svn commit /path/newname

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian. Zauważ, że pakiety updates/ nie powinny zostać zmienione.

Tworzenie pakietu

Jeśli jesteś pewny, że chcesz zbudować pakiet użyj jednej z poniższych metod.

Łatwy sposób

Narzędzie repsys wykona całą pracę za Ciebie. Po prostu, to wykona (przy założeniu, że default_parent jest ustawiony prawidłowo).

UWAGA: repsys jest obecnie w fazie testów beta w repozytorium Mandrivy. Automatyczny skład będzie realizowany (bez konieczności budowania lokalnego).

Tworzenie pakietu cooker z repsys jest łatwe: 

repsys create svn+ssh://svn.mandriva.com/svn/packages/cooker/newpkgname

svn checkout svn+ssh://<repos>/cooker/newpkgname/current newpkgname
Dodaj swoje pliki pakietu

Możesz przywrócić SRPM z pełną zmianą pochodzącą od svn, użyj: 

repsys getsrpm -l pkgname

Wygeneruje to SRPM gotowe do budowy na klastrze

Trudniejszy sposób

Tworzenie pakietu katalogu cooker. Zauważ, że ta operacja wykonywana jest całkowicie w repozytorium: 

svn mkdir svn+ssh://<repos>/cooker/newpkgname

Pobierz kopię modułu do pracy, całego pakietu dir: 

svn checkout svn+ssh://<repos>/cooker/newpkgname /path/newpkgname

Utwórz strukturę w bierzącym katalogu (lokalnie!): 

svn mkdir /path/newpkgname/current 
svn mkdir /path/newpkgname/current/SPECS 
svn mkdir /path/newpkgname/current/SOURCES

Dodaj pliki pakietów do struktury: 

cp SPECS/newpkgname.spec /path/newpkgname/current/SPECS 
cp SOURCES/newpkgname-1.0.tar.bz2 /path/newpkgname/current/SOURCES 
svn add /path/newpkgname/current/SPECS/newpkgname.spec 
svn add /path/newpkgname/current/SOURCES/newpkgname-1.0.tar.bz2

Po zakończeniu prześlij zmiany: 

svn commit /path/newpkgname

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian.

Tworzenie pakietu z innego używając go jako podstawy

Wiele razy pakiet tworzony jest z innego pakietu, używanego jako podstawy. Np. - obecnie Mandriva Linux używa systemu SRPM, gdzie pakiety bibliotek, które posiadają ich nazwę zmieniono w bibliotece soname, więcej niż jedną wersję istniejącą w danym czasie. Mogą być obsługiwane przez przez repozytorium systemu. Załóżmy, że mamy pakiet o nazwie libgal5 i zamierzamy wprowadzić libgal7. Ponieważ nie chcemy utracić historii libgal5 poprostu zrobimy jego kopię i połączymy do libgal7: 

svn cp svn+ssh://<repos>/cooker/gal5 svn+ssh://<repos>/cooker/gal7

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian. Teraz możesz bezpiecznie pobrać moduł libgal7 i pracować nad nim.

Wykrywanie zmian w pakiecie

Aby wyryć co zmieniło się od ostatniego wydania pakietu: 

svn diff svn+ssh://<repos>/cooker/pkgname/pristine svn+ssh://<repos>/cooker/pkgname/current

Aby wykryć to co zmieniło się od wydania danego systemu Mandriva Linux: 

svn diff svn+ssh://<repos>/releases/2005/pkgname/pristine svn+ssh://<repos>/cooker/pkgname/current

Możesz także skorzystać z narzędzia RepSys aby sprawdzić czy pakiet lub pakiety zostały zmienione. By uzyskać więcej informacji sprawdż w RepSys (jeszcze niedostępne) subkomendę "changed".

Zapisywanie dzienników w oryginalnym pakiecie

Jeśli chcesz zachować oryginalny dziennik pakietu możesz to zrobić poprzez stworzenie pliku o nazwie /misc/pkgname/log z oryginalną treścią sesji rpm %changelog bez zmian w samym tagu %changelog. Zawartośc tego pliku zostanie dołączona do zmian logów pochodzących z repozytorium kiedy pakiet zostanie przedłożony do systemu testowego. Oto przykład: 

# Tworzenie i realizacja podkatalogu misc 
svn mkdir svn+ssh://<repos>/misc/pkgname
svn checkout svn+ssh://<repos>/misc/pkgname misc_pkgname

# Wklej zawartość z oryginalnego dziennika BEZ tagu %changelog
vi misc_pkgname/log

# Dodaj do repozytorium i wyślij go

svn add misc_pkgname/log
svn commit misc_pkgname

Korzystanie z oddziałów

Oto pełne wyjaśnienie cyklu oddziału.

Przygotowanie

W naszym przykładzie będziemy zmieniać pakiet openssh do wsparcia kerberos. Ponieważ nie jesteśmy pewni czy ma się stać oficjalnym pakietem w jeden dzień, a my również nie chcemy bałaganu ze zwykłym pakietem openssh, który jest w cookerze (pozostałe można swobodnie zmieniać) będziemy korzystać z jego oddziału.

Pierwszą rzeczą do zrobienia to stworzenie oddziału. Ta czynność jest całkowicie wykonywana w repozytorium, więc nie ma szans na błędy. 

svn cp svn+ssh://<repos>/cooker svn+ssh://<repos>/branches/openssh-krb

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian.

Korzystanie

Teraz, gdy mamy oddział, pobierzemy kopię modułu pakietu openssh do naszej pracy, z oddziału: 

svn checkout svn+ssh://<repos>/branches/openssh-krb/openssh/current /path/openssh-krb

Teraz w miarę potrzeby możesz go zmienić. W naszym przykładzie mamy zamiar wprowadzić nową łatkę zwaną openssh-krb.: 

# dodaj plik 
cp openssh-krb.patch /path/openssh-krb/SOURCES 
svn add /path/openssh-krb/SOURCES/openssh-krb.patch 
 
# Wprowadź niezbędne zmiany do łatki
vi /path/openssh-krb/SPECS/openssh.spec 
 
# Prześlij swoje zmiany 
svn commit /path/openssh-krb

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian.

Prawdopodobnie zechcą wydania testowego pakietu z twoim zmienionym openssh. Aby to zrobić należy użyć jednej z technik opisanej wyżej w sekcji "Testowanie pakietu".

Połączenie powrotne

Po kilku tygodniach zmian i badań zdecydowaliśmy się użyć tych zmian w naszym głównym pakiecie cooker. To czas na scalenie naszej pracy.

Po pierwsze, pobierz do pracy kopię modułu pakietu openssh z cookera: 

svn co svn+ssh://<repos>/cooker/openssh/current /path/openssh

Następnie musimy znać zmiany, które stworzyliśmy w naszym oddziale, dzięki temu będziemy mogli połączyć zmiany wprowadzone w tym okresie. To polecenie pomoże nam w zadaniu: 

svn log svn+ssh://<repos>/branches/openssh-krb | head -n 2

Teraz wiemy, że zmiany (powiedzmy 18003) spróbujemy połączyć pracując w pliku spec oddziału openssh-krb. 

svn merge -r 18003:HEAD svn+ssh://<repos>/branches/openssh-krb/openssh/current/SPECS/openssh.spec /path/openssh/SPECS/openssh.spec

UWAGA: NIE wystarczy skopiować plik z oddziału ponad plik cooker, ponieważ może on zawierać nieznane zmiany.

Jeśli powyższe polecenie wskarze wszystkie konflikty, należy je rozwiązać przed podjęciem następnego kroku.

Musimy również niezależnie sprawdzić, czy pliki zostały wprowadzone lub usunięte w oddziale i pracują w pakiecie cooker. Znowu, NIE wystarczy skopiować stamtąd plików ponad cookera. Sprawdź jakie zmiany zostały dokonane przez użytkownika oddziału oraz jakie zmiany zostały wprowadzone przez innych w cookerze. Być może łatwo to zrobisz z następującego polecenia: 

svn log -v -r 18003:HEAD svn+ssh://<repos>/branches/openssh-krb/openssh/current 
svn log -v -r 18003:HEAD svn+ssh://<repos>/cooker/openssh/current

Zakładając, że w cookerze nie wprowadzono żadnych zmian, z powyższego polecenia znajdziesz wprowadzoną łatkę w naszym pliku openssh-krb. Zamiast po prostu ręcznie wprowadzć pakiet openssh do katalogu SOURCES/ w cookerze i dodanie do subversion, skopiuj za pomocą subversion aby subversion będzie używał wewnątrz tych samych danych do reprezentowania obu. Będzie to prostsze niż się spodziewasz: 

svn copy svn+ssh://<repos>/branches/openssh-krb/openssh/current/SOURCES/openssh-krb.patch /path/openssh/SOURCES

Zauważ, że po dodaniu go do naszej kopii, wszystko zostanie wykonane w jednej operacji: 

svn commit /path/openssh

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian.

Usuwanie oddziału

Ok. Jesteśmy gotowi! Oddział openssh-krb został włączony do cookera. Teraz bezpiecznie możemy usunąć nasz oddział: 

svn rm svn+ssh://<repos>/branches/openssh-krb

UWAGA: Proszę zapoznać się z sekcją "wiadomości zmian" przed wejściem do dziennika zmian.

Wskazówki

  • Zmiana na miejscu plików w kopii. Nie nadpisuj pliku w katalogu kopii roboczych z zewnętrznego pliku.
  • Jeśli naprawdę ma zastąpić plik w kopii roboczej, wykonaj działania svn diff aby upewnić się, że naprawdę to zmieniasz czego oczekujesz.
  • Użyj oddziałów jeśli chcesz odgałęziać rozwój pakietu przez dłuższy czas.
  • Użyj oddziałów do testowania nowej wersji oprogramowania, które nie powinny jeszcze trafić do cookera.
  • Zachowaj ostrożność podczas pełnego oddziału repozytorium, jak w powyższym przykładzie. To może trwać trochę dłużej (zrobiłem to już teraz przez 31 minut)

Kontakt

Aby uzyskać informację na temat tego systemu, skontaktuj się z:

Źródło „http://wiki.mandriva.com/pl/Rozw%C3%B3j_systemu/Pakiety/Repozytorium”
Ad (via La Vignette)
Looking for a job?