PROBLEM: cvs i puchnięcie (znowu)

[Tomasz Kłoczko]

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.
  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,
  - 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,
* 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,
* 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,
* forsowanie http/DAV jako protokołu transportowego.
  Dlaczego nie kompletnei włąsny protokół zoptymalizowany pod kontem 
  repozytorium ?
* 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,
* 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")

subversion nie rozwiązuje w sumie żadnego z mankamentów cvs jakie są
dotkliwe na serwerach 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).
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.

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).
IMHO skórka nei jest warta wyprawki bo subversion wcale po mimo tego że 
tak pisza jego autorzy nie jest aż tak lepsze od cvs :)

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*