subversion, cvs etc - efektywność svn diff, inne WebDAV z apache-mod_dav

Marek Guevara Baun marek.guevara w atm.com.pl
Pon, 14 Kwi 2003, 14:46:16 CEST


Andrzej Krzysztofowicz wrote:
>>A poważnie to z tego co widać, że subversion możemy używać dokładnie tak
>>jak CVS teraz, modulo to, że nie można kasować tarballi, co stanowi
>>problem sprzętowy.
> 
> ZTCW kloczek chcial przeniesc / przeniosl SOURCES/Attic na inna maszyne
> z powodu oszczednosci miejsca.
> Widzisz to w subversion ?

Czy ktoś ma doświadczenia na ile svn diff jest skuteczny


Jeśli binarny diff svn-owy jest prostym diffem to teoretycznie,
w dłuższej skali czasu, bardziej efektywne (dla zużytego
miejsca na dysku) byłoby przechowywanie źródeł programów w postaci
rozpakowanej.

Jeśli natomiast svn diff radzi sobie ze skompresowanymi plikami w taki
sposób, że najpierw je dekompresuje, a dopiero potem robi jakiegoś
inteligentnego diffa - wtedy rzeczywiście jest szansa, że repozytorium
svn nie rozrośnie się do monstrualnych rozmiarów po kilku zmianach
w binarkach.

Co do wykorzystania rozpakowywanych źródeł (sam rozmiar przy transmisji
sieciowej nie powinien być tu problemem gdyż jest szansa że ktoś kto
ściąga pakiet ma starszą wersję źródeł i dostaje tylko diffa,
a i sama transmisja svn/ssh lub http może być kompresowana)
skrypt builder widząc w specu wpis typu
Source0:   http://www.example.com/path/kernel-2.7.66.tar.bz2
zamiast najpierw cvs-ować kernel-2.7.66.tar.bz2 z SOURCES
svn-ował by drzewo/moduł kernel-2.7.66 (lub kernel z release
2.7.66) i po skompresowaniu do tar.bz2 (czego może dało by
się uniknąć) wrzucał do lokalnego SOURCES

Podstawowym testem na svn w dzisiejszej postaci (z tylko jednym
backendem fs) może być wpakowanie po kolei do svn wszystkich
wydań kernela od 2.4.0 do 2.4.20 i sprawdzenie czy rozmiar
pliku DB nie równa się sumie wielkości wszystkich archiwów.

Można jeszcze pomyśleć (gdyby svn nie był idealnym repozytorium
dla binarek) o rozdzieleniu repozytoriów SPECS i SOURCES
i wykorzystaniu do tego ostatniego "czystego" apache-mod_dav
z implementacją mod_dav_fs w postaci plików, które w łatwy
sposób można likwidować po stronie apache (nawiasem mówiąc
Subversion dostarcza do Apache swój własny odpowiednik
mod_dav_fs w postaci mod_dav_svn).

Sam WebDAV daje możliwość przypisania obiektom pewnych etykiet
i ich odczytania (metody PROPPATCH i PROPFIND) do których można
mieć dostęp np. z poziomu klienta dave (command-line shell)
lub modułu perlowego HTTP-DAV (widziałem jeszcze narzędzia
pythonowe, no i lib neon).

Etykiety te mogą zawierać takie metainformacje jak nazwa speca
z CVS/SVN, wersja, release, branch - dostęp do repozytorium
możliwy był by po http/https - wystarczy "tylko" nauczyć
builder wykorzystania odpowiedniego narzędzia/skryptu do
ściągnięcia właściwego release.

Same commity SOURCES można oskryptować m.in. w HTTP-DAV (perl)
lub też używać shella dave.

Pozdrawiam,
Marek

-- 
Marek Guevara Braun	<mguevara_pld_org_pl>



Więcej informacji o liście dyskusyjnej pld-devel-pl