Raport mniejszości (było: Re: subversion)

[Tomasz Trojanowski]

Witam!

Powiem jedno. Malekith!!! przestań czytać w moich myślach -- całą 
niedzielę spędziłem na myśleniu jak by zrobić sobie dobrze przy pomocy 
Subversion ;)

OK. A teraz merytorycznie

On Sun, 14 Sep 2003, Michal Moskal wrote:

> [...cut...]
> 
> W subversion nie ma czegoś takiego jak tag lub moduł. Czasami stosuje
> się praktykę, że tworzy się repozytorium dla danego projektu. My takiej
> praktyki nie stosujemy.
> 
> Zamiast modułów i tagów są dobrze wszystkim znane katalogi i pliki. Tagi
> i branche realizuje się przez kopię drzewa plików. Np. chcąc otagować
> pliki projektu foo robimy tak:
> 
> svn cp http://svn.pld-linux.org/foo/trunk \
> 	http://svn.pld-linux.org/foo/tags/foo-1.0
> 
> (Co dodaje do bazy pare bajtów, a nie pare megabajtów jak można by
> sądzić).
> 
> Stąd wynika struktura repo: 
> 
>   <projekt>/trunk    -- cvsowy HEAD
>   <projekt>/tags     -- tagi
>   <projekt>/branches -- branche
> 
> Ale jest to czysto umowne.
> 
> Dla PLD struktura mogłaby wyglądać tak:
> 
> PLD-packages/
>   mozilla/
>     tags/
>       1.0-1/
>         SPECS/
> 	  mozilla.spec
> 	SOURCES/
> 	  mozilla-foobar.patch
>       1.0-2/
>         ...
>       auto-ac-1.0-1/
>         ...
>     branches/
>       devel/
>         SPECS/
> 	  mozilla.spec
> 	SOURCES/
> 	  mozilla-foobar.patch
>     trunk/
>       SPECS/
>         mozilla.spec
>       SOURCES/
>         mozilla-foobar.patch

Widziałbym to trochę inaczej. Najpierw struktura, a potem skomentuję

packages/
  gcc/
    gcc.spec
    SOURCES/
  binutils/
    binutils.spec
    SOURCES/
  setup/
    setup.spec
    SOURCES/
branches/
  gcc/
    Ra-branch/
      gcc.spec
      SOURCES/
    Ac-branch/
      gcc.spec
      SOURCES/
    DEVEL/
      gcc.spec
      SOURCES/
tags/
  gcc/
    gcc-3.3-1/
      gcc.spec
      SOURCES/
    gcc-3.3-2
      gcc.spec
      SOURCES/

No i komentuję.

To wszystko oczywiście przy założeniu, że na potrzeby SOURCES/SPECS 
przeznaczamy osobne repozytorium, bez jakichkolwiek innych projektów w 
nim.


Trzymanie osobno specy i źródeł ma tę zaletę, że pozwala je jednym 
poleceniem ściągnąć z repozytorium. Druga sprawa, w związku z troszkę inną 
koncepcją tworzenia branchy i tagów, pozwala (również jednym poleceniem)
stworzyć branch lub taga dla całego pakietu.

No i mass commity nie będą już takie proste :P

Wiązałoby się to niestety, z odejściem od struktury katalogów w ~/rpm, 
takiej jak oferuje rpm. 

Wymagałoby to zmian w /usr/lib/rpm/macros jak poniżej. Założyłem że rpm 
rozwiązuje poprawnie makro %{name} przy budowaniu pakietu -- nie 
sprawdzałem.

%_topdir	%(echo $HOME)/rpm
%_builddir	%{_topdir}/BUILD
%_rpmdir	%{_topdir}/RPMS
%_srcrpmdir	%{_topdir}/SRPMS
%_sourcedir	%{_topdir}/packages/%{name}/SOURCES
%_specdir	%{_topdir}/packages/%{name}

Tu jest niestety najsłabsza punkt tej koncepcji, nie wiem czy powyższe 
będzie działać. A jeśli nawet będzie to czy nie spowoduje jakichś 
kłopotów.


Pozostaje jeszcze kilka problemów na które natknąłem się w trakcie 
używania Subversion:

1. Subversion nie obsługuje "$Log$", w związku z tym nie jest możliwe 
   tworzenie %changelog tak jak to ma miejsce w starym repozytorium. Nie 
   wiem na ile można to rozwiązać w hooks/pre-commit.tmpl, bo nie wiem czy 
   istnieje możliwość modyfikacji plików w repoztytorium z poziomu tego 
   skryptu.

2. Nie wiem jak automatycznie ustawiać
     svn propset svn:keywords "Id Date Rev" foobar.spec
   dla każdego pliku *.spec. Pozostaje ustawianie wszystkich indywidualnie 
   dla każdego pliku.

To na razie tyle.

-- 
Tomasz Trojanowski (tomek w uninet.com.pl)

"Between depriving a man of one hour from his life and depriving him of
his life there exist only a difference of degree." (FH, Dune Messiah)