PROBLEM: cvs i puchnięcie (znowu)

[Tomasz Kłoczko]

On Sun, 16 Mar 2003, Bartłomiej Ogryczak wrote:

> Tomasz Kłoczko wrote:
> 
> >>>Jest kiepsko :>
> >>>Otóż cvs puchnie (tak jak to juz bywało niegdyś).
> >>>
> >>>Mam .5G RAM i ponad 2GB swap. Średnio wszystko się mieści w pamięci i swap 
> >>>dotykany jest w pikach do kilkudziesiąt MB. Przy ciągnięciu dużych plików
> >>>(zapewne źródła OO) całość puchnie do poziomu przy którym cvs server 
> >>>wylatuje z out of memory.
> >>
> >>CVS wyjątkowo słabo nadaje się do serwowania dużych binarów.
> >  
> > Z racji kiepskiej gospodatrki pamięcią.
> 
> To akurat kwestia wtórna. W CVS-ie obsługa binarek jest zrobiona na
> "odwal się". Nie wykorzystuje żadnego xdelta ani nic takiego, tylko
> po każdej zmianie serwuje cały plik.

W sumie rozbudować to o taki elemet nie byłoby trudno. Dla klienta bedzie 
to pzreźroczyste. Protokół nie wymusza formy przechowywani historii 
zmian. Na SF zdaje się że zresztą że używaja jakiegoś SQL backendu.
Nic nei stoi na przeszkodzie żeby cvs serwer używał dodatkowo plików w 
innym formaci np. aegisa czy innych. Wystarczy ze sprawdzałby czy jest 
<plik>,v i o ile nie ma szukał tego samego pliku ale w kolejnym 
zdefiniowanym formacie.

> O ile mnie pamięć nie myli CVS nie ma żadnego mechanizmu wznawiania
> transmisji. Dochodzi jeszcze problem blokowania. Albo wrzucisz pliki do
> pamięci na czas transmisji, albo masz na cały czas transmisji
> zablokowany cały moduł.

To też jest hore bo blokowanie powinno być na poziomie plików i/lub 
powinna być możliwiosć konfigurowania tego czy ma to byc robione na plik 
czy moduła czy też podkatalog w module.
Znowu .. to jest to dorobienia i nic nie stoi na przeszkodzie zeby to 
zrobić, a efekt jaki czasem występuje u nas będzie wystepował w każdym 
większym module w jakimkolwiek repo.

> Po stronie klienta też niefajnie. Ściągając duży plik CVS-em nic innego
> w tym czasie w CVS-ie nie zrobisz. To nie jest problemem, kiedy owymi
> binariami są np. pliki PNG wielkości do 50KB, ale już kiedy są to pliki
> rzędu 30MB-150MB, a download osiąga zawrotną prędkość 5KB/s to jest
> problem.

To już jest raczej kwestia szerokości rury :)

> W dodatku nie wiadomo kiedy połączenie się zerwie i trzeba będzie
> ciągnąć od początku. Podsumowując - trzmymanie tar.gz w CVS-ie to
> totalna porażka.

Raczje porażką jest to, że nie mamy nadal automatu który śledziłby zmiany 
w SPECS i wycinałby to co nie jest juz używane dodajac jednoczęsnie to co 
moze dociagnąć na podstwaie adresu w SOURCES.

> Pewnym rozwiązaniem byłby zastąpienie CVS-a przez
> Subversion, ale nadal byłby to rozwiązanie połowiczne. Najlepiej byłby
> jednak serwować źródła przez FTP/HTTP. Niekoniecznie z oryginalnymi
> nazwami, mogą mieć np. doklejony timestamp albo numer(y) wersji SPEC-ów.

subversion operuje via HTTP (IIRC) czyli też nie ma reget. reszta rzeczy 
jest niezależna od protokołu a od tego co sie dziej po stronie serwera.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*