PROBLEM: cvs i puchnięcie (znowu)

[Arkadiusz Miskiewicz]

On/Dnia Mon, Mar 17, 2003 at 07:39:26PM +0100, Tomasz Kłoczko wrote/napisał(a)
> On Mon, 17 Mar 2003, Michal Moskal wrote:
> 
> > On Mon, Mar 17, 2003 at 03:44:07PM +0100, Robert J. Wozny wrote:
> > > Quoting Michal Moskal <malekith w pld-linux.org>:
> > > 
> > > >> Ale chyba przyznasz, że powinien mieć ograniczenie wielkości bufora... 
> > > > Ojej... cokolwiek. CVS to przestarzała technologia i powinniśmy się
> > > > zastanawiać się jak się najszybciej od niego uwolnić.
> > > 
> > > a co w zamian?
> > 
> > subversion.
> 
> Mam kilka "przeciw" subversion:
> * cvs serwer przekazuje klientowi diffa w stodunku do rewizji jaką 
>   twierdzi że ma, a w druga  stronę idzie jawnie całość.
>   sunversion przesyła diffy w obie strony.
To jest zaleta, a nie wada. 

>   Ale:
>   - zawsze wiekszość operacji na repo to odczyty, a nie zapisy (stosunek 
>     jest conajmniej 10:1 jak nie 100:1 i wiecej czyli oszczednosć w sumie 
>     bardzo mała i/lub żadna,
Operacje jak robienie xdelty są afaik robione lokalnie bez udziału serwera.

>   - wprowadzajac diffa na serwer dochodzi sprawa z tym że commit może się 
>     nie udać i nie można nic innego zrobić jak usunąć to co przeszkadza i
>     ponowić commit. Z tego co widziałem opinie innych nie jest to wcale 
>     zdażenie żadkie i w sumie jest to jeden z częściej wymienianych 
>     argumentów przeciw,
Jaki tu widzisz problem w subversion? Commity są atomowe.

> * subversion w małym stopniu jest podobne w operowaniu na repo do cvs.
>   Nie mam pojęcia dlaczego ludkowie którszy to robia nie zabrali się za
>   poprawianie cvs i/lub rozrzerzanie funkcjonalnosci czy zmienianie tego 
>   co jest po stronie serwera,
Dlatego, że prościej było napisać from scratch niż poprawiać cvs.

> * z racji tego że cvs ma wiadomą streruktóre plików repozytorium
>   (rcs) jest możliwe używanie operowanei na repo bez sieci tym samym 
>   żeby założyć repo nie tzreba wogóle sie nikogo ptać i można mieć to we 
>    własnej przestrzeni zasobów,
Podobnie jest w subversion. Zamiast rcs używa się db4. Można bez
problemu operować bez sieci.

> * forsowanie http/DAV jako protokołu transportowego.
>   Dlaczego nie kompletnei włąsny protokół zoptymalizowany pod kontem 
>   repozytorium ?
Zapewne dlatego, że jest to dobre rozwiązanie. Nie rozumiem co oznacza
,,optymalizacja pod kątem repozytorium''. Co tu optymalizować?

> * forsowane jest użycie raczje http/DAV zamiast standalone wersji 
>   serwera - http jest czymś znacznei wiekszym i wraz z nim przychodzi 
>   cały bagaż jego własnych ograniczeń i błędół które kryją się jego 
>   własnym kodzie,
Nie jest forsowane. Wybierasz co Ci pasuje, a nie to czego używa
większość:
http://subversion.tigris.org/project_faq.html#need-apache

> * większosć funkcjonalności subversion możńaby zrealizować on top
>   cvs-a z Cyclic jak to próbują robić ludzie on cvs-nserver 
>   (zgodnie z zasadą: "don't move .. improve")
Co było by równoznaczne z przepisaniem cvs od nowa hehe :)

> subversion nie rozwiązuje w sumie żadnego z mankamentów cvs jakie są
> dotkliwe na serwerach 
Bo rozwiązuje wiele problemów widocznych od strony użytkownika SCM, a
nie administratora. O to właśnie w subversion chodziło.

> jak przekierowywanie odczytów na zapasowe serwery z
> zasobami na których operuje się bez blokowania czegokolwiek.
> Nie ma replikacji i redundancji, a takze rozproszenia zasobów serwerowych 
> (co ma bk i np. aegis).
AFAIK nie mają póki co w planach zabawy w rozproszone repo. 

> Zabawa z inną metodologią obsługi branchowania jest w sumie bardziej
> kwiatkiem do korzucha bo nie to są największe w tym wszystkim mankamenty,
> a bez tego co jest w subversion w tej dziedzinie daje się spokojnie żyć i
> pracowac co potwierdza otoczenei ze prawie wszyscy uzywaja cvs (czasami
> jeszcze rcs) i mało kto subversion. Wynika to z twego że subversion ma 
> raczje swoje własne cele/kierunki rozwoju nie pokrywajace się z tym czego 
> potzrebują ludzie używajacy cvs i co chcieliby żeby było prędzej czy 
> później rozwiązane.
Dało się żyć i bez SCM. Tu nie o to jednak chodzi, że się da żyć tylko,
że można robić wiele rzeczy wygodniej.

> Nie dość powiedzieć, że wcale nie małą ilość rzeczy dla których zabrano
> się za subversion jest już rozwiazancyh w cvs-nserver (lepsze 
> bezpieczeństwo wynikajace z lepszej separacji kodu serwera i klienta, 
> lepsze zarżadanie repo i kilka pomniejszych).
Akurat to jest niemal nieistotne.

> kloczek

-- 
Arkadiusz Miśkiewicz    CS at FoE, Wroclaw University of Technology
arekm w sse.pl   AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux