Subversion, CVS i wielkie binarki (Było Re: Znowu locki w CVS)

[Michal Moskal]

On Wed, Dec 04, 2002 at 11:50:08PM -0500, Filip Kalinski wrote:
> Dnia Wed, Dec 04, 2002 at 10:57:33PM +0100, Mateusz Korniak  co następuje:
> > On Thursday 05 of December 2002 04:36, Filip Kalinski wrote:
> > 
> > > > Żeby commity były atomowe. (żebyś nie mógł wyciągnąć źródeł w środku
> > > > commitu) Ale i tak nie są, znaczy teoretycznie są, ale tylko w obrębie
> > > > jednego katalogu ;-) Anyway polecam subversion.
> > >
> > > Który pliki trzyma w bazie danych. Czyni go to bardzo przydatnym do
> > > trzymania wielkich binarek ;-)
> > 
> > Sugerujesz że to jakiś problem dla współczesnej bazy danych ?
> > Albo że CVS jest pod tym względem lepszy :) ?
> > 
> 
> Chodzi o plikową bazę danych na bibliotece db4. CVS mimo wszytko chyba jest
> lepszy.

*Jeśli* trzymamy binarki w systemie kontroli wersji, to rzeczywiście svn
nie jest dobrym rozwiązaniem. CVS jest trochę lepszy, ale jak widać
również nie bardzo się nadaje. *Żaden* system kontroli wersji nie jest
przystosowany do trzymania w nim N-megowych binrek, bo niby po co?

System kontroli wersji służy do (tadam!) *kontroli wersji* a nie
serwowania plików. Zauważ, że 99% tarballi w SOURCES nie wymaga żadnego
wersjonowania -- są one jednoznacznie identyfikowane przez nazwę.
Pozostałe 1% można by spokojnie trzymać w katalogach z numerem wersji.

Mogłoby to wyglądać tak:

SOURCES/ i SPECS/ zostają tak jak są teraz. Tyle że w tarballe w sources
są zastąpione jakimiś małymi plikami z linkiem do ftp/http gdzie są
prawdziwe tarballe. Np.:

linux-2.4.20.tar.bz2:

#v+
###<PLD Source Link magic>###
kernel/2.4.20/linux-2.4.20.tar.bz2
ftp://ftp.kernel.org/some/path/linux-2.4.20.tar.bz2
#v-

builder jeśli zobaczy '###<PLD Source Link magic>###' w pierwszej linii,
czyta drugą, robi:

  wget $(echo $druga | sed 's|^|http://sources.pld.org.pl/tarballs/')

I tyle. Druga linijka mogłaby służyć do automatycznego ściągania źródeł
na sources.pld.org.pl. 

Potem można by pomyśleć nad rozdzieleniem SPECS/ i SOURCES/ na
podkatalogi dla każdego pakietu, np.:

packages/
  foobar/
    branches/
      head/
        foobar.spec
        tarballs/
          foobar-1.2.3.tar.gz
        patches/
          foobar-make.patch
      devel/
        foobar.spec
        tarballs/
          foobar-2.1.2.tar.gz
        patches/
          foobar-ac.patch
          foobar-make.patch
    versions/
      1.2.1-1/
        foobar.spec
        tarballs/
          foobar-1.2.1.tar.gz
        patches/
      1.2.3-1/
        foobar.spec
        tarballs/
          foobar-1.2.1.tar.gz
        patches/
          foobar-make.patch

W takim schemacie (przewidziany dla subversion, a nie CVS, wyjaśnienia
niżej [1]), wszystkie pliki w */tarballs/ mogą być z definicji linkami. 
Oczywiście to wszystko wymaga dużych zmian w skrypcie builder (musiałby
jakoś te pliki dać rpmowi).

[1] SVN repo widoczne jest jako filesystem. Nie ma żadanych branczy,
filesystem jest wersjonowany liniowo. Dowcip polega na tym, że
filesystem jest wewnętrznie reprezentowany jako DAG (skierowany graf
acykliczny) i wykoanie operacji typu 

  svn cp http://foobar/SOURCES/ http://foobar/SOURCES-copy/

Gdzie SOURECS ma 50M, dodaje do bazy kilkadziesiąt bajtów. Po prostu
SOURCES-copy/ jest linkiem do SOURCES w *wersji* 1423.

Tagi i branche są więc reprezentowane przez katalogi. Jest to IMHO
znacznie bardziej intuicyjne, niż to co mamy w CVS.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h