Re: lug-bg: wget -m

[George Danchev <danchev@xxxxxxxxx>]

On Tuesday 08 June 2004 19:47, Peter Pentchev wrote:
> On Tue, Jun 08, 2004 at 07:20:45PM +0300, George Danchev wrote:
--cut--
> > Е CVS протокола е с пъти по-тежък/усложнен от rsync протокола и това е
> > защото cvs протокола е предвиден да се разправя с
> > rcs-files/versioning/tags/alabala. Това е едно от големите му недостатъци
> > и вероятно причина да се измислят по-ефективни протоколи като SVN.
>
> Чакай, чакай... нали не мислиш, че CVSup използва същия протокол, който

Мда не го написах правилно, трябваше да нашиша "CVS и CVSup протоколите..."

> се използва между CVS клиент и CVS сървър при check-in, check-out, log,
> status и т.н.? :)  Всъщност двете нямат нищо, ама нищо общо :)

Ами да ти кажа честно doc/Protocol в сорса на CVSup много ми прилича на CVS 
протокола, ама много... същата сложност... не казвам, че съм спец по CVS 
протокола де.. но не искам да спорим доколко CVSup протокола е по-лек от CVS. 
А иначе ясно е, че са различни защото отгоре на doc/Protocol седи копирайта 
на jdp Джон Полстра.

> Когато CVSup установи, че това, което прехвърля, е RCS/CVS version file,
> то "по жицата" се прехвърля много бързо информация за това кои
> revisions, tags, branches има при клиента, и ако при сървъра няма нищо
> друго, не се прави нищо.  Ако се окаже, че има разлики, се предават само
> разликите *като diffs*, т.е. като RCS revision info.  Според мен това би
> могло да бъде много по-бързо от опитите на rsync да намери разликите във
> файловете по една проста причина: CVSup вече *знае* точно къде са
> разликите във файловете, точно от кое отместване във файла започват,
> къде свършват и т.н., и изобщо не се опитва да сравнява останалите части
> от файловете.  Е, накрая се прави някаква checksum, за да се убедят
> клиентът и сървърът, че наистина имат един и същи файл де :)

Ама, абсолютно съм съгласен, и в предното писмо ако погледнеш пак ще видиш, че 
съм сравнил два Revision_Control_System протокола като CVS и SVN 
(subversion) ... Все още съм на мнение, че CVSup протокола не е с пъти 
по-олекотен от CVS протокола (много си приличат даже), който пък е с пъти 
по-тежък от SVN (но това си е мое мнение, де). Т.е. това е случая когато 
имаме информация за съдържанието/разликите на файловете. 
Втория случай, когато нямаме информация за съдържанието/разликите на 
файловете, всички използват RSYNC протокола, включително и самата програма 
cvsup, само, че явно със собствена имплементация на този протокол, а не както 
rduff се обляга на librsync.

> Като цяло rsync протоколът е замислен за минимално количество мрежов
> трафик *без никаква информация за съдържанието на файловете*, затова на
> моменти използва доста интересни алгоритми (това с rolling checksum е
> *прекрасна* идея), някои от които са описани в technical report-а на
> http://rsync.samba.org/tech_report/  Това е много хубаво, когато
> наистина никой не знае нищо за файловете, но според мен (а явно и според
> John Polstra) допълнителната информация, съдържащата се в headers на RCS
> files, може да спести доста анализ и претърсване за съвпадащи блокове.

Сигурен ли си, че няма случаи когато да се анализират и трансферират *само* 
описанието на разликите между два файла е повече трафик отколкото ако направо 
се предаде новия файл ;-) Напиши си едно файлче 100 реда, въведи корекции 
през ред (това ratio май е много убииствено, аре през два реда ;-) и извади 
най-евтиния diff между двата файла и ще видиш, че ще е по-голям от всеки от 
тези файлове взети поотвелно, а ако въведеш промени на всеки ред в първия 
файл, най-вероятно резултантния най-евтин diff ще е по-голям и от двата файла 
взети заедно... Така, че "паразитната" описателна информация може и да 
пречи... Освен ако cvsup не използва някакъв супер евтин алгоритъм за 
дифф ;-)

Хайде няма да извеждаме и чертаеме графика на двете функции с описателна и без 
описателна информация и да гледаме къде се пресичат, демек точката в която 
няма значение дали ще има или няма такава информация то трансфера ще е един и 
същи и при какво количество промени ще пречи една такава допълнителна 
информация и където започвайки да я анализираш вече си вътре с трафика... 
Тема за анализ за ФМИ, not me ;-) 

> > А за non-rcs-files CVSup използва rsync протокола, явно собствена
> > имплементация, а не направо librsync(3) явно поради езикови различия.
> > Така, че както в случая се джиткат non-rcs-files, и се използва rsync
> > протокола/алгоритъма, то аз лично предпочитам да използвам програмата
> > rsync.
>
> Can't argue with that.. или поне в момента няма да се опитвам :P

Good.

-- 
pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================