🚀 go-pugleaf

> Ewa Murawska <emurawsk@vic.design.telstra.com.au> wrote:
> > Na UNIXie jest CVS, ktory nadaje sie do wszystkiego. Z tym
> > do czego sie nie nadaje nie spotkalam sie w 7 letniej
> > praktyce (co nie oznacza, ze czegos takiego nie ma). Tyle
> > ze nie jest okienkowy (ClearCase jest i latwo widac
> > branches), co niektorym moze sie wydawac zacofaniem ;-).
> 
> Właśnie, mam zamiar wprowadzić CVS w firmie (duży projekt - 
> zgrubnie koło setki klas, na razie 3 programistów, będzie więcej),
> jedno co mnie nie niepokoi to informacja że locking jest tam na
> poziomie plików - czyli możliwe jest że ktoś będzie wykonywał 
> commit a inny update - i ten kto ściąga nowe wersje otrzyma część
> plików nowych a część starych, czyli będzie miał niespójną
> wersję projektu.
> 
> Oczywiście może później wykonać jeszcze raz update, ale może
> jest jakiś ogólnie znany sposób zabezpieczenia się przed taką
> sytuacją?
> 
> -- 
> Piotr Piątkowski, Kraków

Szybko przelecialam przes moj projekt i mamy tam okolo 700 klas.
Kazda z klas ma na ogol swoj wlasny plik (a dokladnie dwa:
header i source). W CVS przechowujemy dodatkowo unit tests,
pliki binarne (dane) i rozne inne duperele.
To jest tylko srodowisko dla programistow. Mamy tez testerow,
ktorzy maja caly swoj zestaw testow i danych, tez pod CVS.

Co do lockowania, to faktycznie takie istnieje, ale nie da sie
zrobic czegos takiego jak opisana przez ciebie sytuacja.
Jak zaczynam robic commit, to blokuje dostep do CVS i nikt
wtedy nie moze zrobic update. Oczywiscie nie musze robic
wszystkiego w jednym commit i komus moze sie udac zrobic
w miedzyczasie update. W praktyce mozna sobie wypracowac
procedure, ze jak ktos zrobi commit jakiejs porcji kodu,
to informuje o tym innych. Mozna tez ustawic swoje
srodowisko pracy tak aby automatycznie dostawac informacje
o dokonanych zmianach. Nie wiem jak i gdzie to zrobic, bo
sama tego nigdy nie robilam, ale w jednej z prac tak wlasnie
bylo.
Jezeli ktos chce sie upewnic, czy ma wszystko uaktualnione,
ale bez uaktualniania (jezeli jednak by sie okazalo, ze
ktos inny w miedzy czasie dokonal jakich zmian) to taka
opcja w CVS istnieje.
Moim zdaniem problem blokowania choc teoretycznie istnieje,
to praktycznie nie ma specjalnie znacznia. W praktyce
kazdy programista ma swoja "work area", gdzie dokonuje
zmian. Dobrze jak od czasu do czasu zrobi cvs update,
zeby miec te "spojna wersje plikow". Oczywiscie im
czesciej sie to robi, tym miej czasu traci sie potam na
ewentualna rekomplilacje roznych bibliotek.

CVS ma jedna wade. Zalozmy, ze osoba A i B startuja z ta
sama wersja danego pliku.
Hmmm... Czy kogos to jeszcze interesuje?? No, ale brne dalej.
A cos zmienia i robi commit. B tez cos zmienia i robi
commit bez uprzedniego zrobienia update. Wiem, ze
w wersji, ktora uzywalam pare lat temu plik commitniety
(jak to po polsku napisac?) przez B, przeslanial nowa wersje
pliku pochodzaca od A. Nie wiem jak jest teraz, ale
kazdy kto uzywa CVS ma we krwi robienie update zanim
zrobi commit.

Jest jeszcze jedna rzecz, dotyczaca usuwania katalogow
z CVS. Zeby za bardzo nie nudzic, szczegoly moge dostarczyc
ewentualnym zainteresowanym.

A! Jest jeszcze jeden proces, ktory faktycznie blokuje
CVS. Blokuje z sposob raczej "logiczny" niz fizyczny.
Jest to laczenie (merge) branches (przepraszam za
niewysilianie sie nawet na polski odpowiednik).
Na ten czas dobrze jest, zeby wszyscy zaniechali
uzywania CVS, bo jakies zmiany moga wtedy zostac
pominiete w tym czy w kolejnym merge. Merge nie
jest latwa czynnoscia, ale i nie dokonuje sie
tego codziennie. Niektore projekty moga sie bez
tego swobodnie obejsc.
Czas w jakim dokonuje sie merge zalezy od roznic
w branches (oczywiscie), zarowno od ich ilosci
i jakosci. U nas trwalo to srednio 1 do 4 dni
(4 dni to bylo przy upgrade systemu operacyjnego
i zainstalowaniu oprogramowaniu zgodnego z y2k).
Nie wiem czy system jest duzy czy maly. Szybki
lot nad plikami .*c* i .h* pokazal ich liczebnosc
w okolicach 1700 i 1100.

Wiecej mi nie przychodzi na razie do glowy.
Ogolnie nie znam slyszalam o niczym lepszym
(czytaj: czesciej uzywanym) na UNIXe.

Pozdrowienia,
Ewa