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 ============================================================================
