🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.objects
Article #5047

Re: CVS [było o UML]

#5047
From: Ewa Murawska
Date: Thu, 11 Mar 1999 21:52
56 lines
3555 bytes
> Ewa Murawska wrote:
> > [...]
> > 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 pamiętam, żeby tak kiedykolwiek było w CVS-ie.
Nie probowalam jak jest teraz, wiec sie nie upieram. Z tym problemem
zetknelam sie jakies 5-6 lat temu, wiec mozliwe, ze byl, ale
w kolejnych wersjach juz go nie ma.
Spytalam speca obok i powiedzial, ze teraz CVS sie zbuntuje w
momencie proby commita pliku, ktory zostal wczesniej przez kogos
innego uaktualniony w CVS. Czyli jest tak jak piszesz dalej.
  
> Jest tak - załóżmy, że najpierw w CVS-ie jest wersja 1 pewnego
> dokumentu. A dodaje poprawki i je commituje. Teraz na serwerze jest
> wersja 2. B ma ciągle 1. Teraz B robi swojego commita. Przy commicie
> dokument nie zostanie włączony do archiwum, poniewaz w archiwum znajduje
> sie wersja wyzsza od lokalnej. Z kolei update spowoduje, ze na serwerze
> zostanie wygenerowany patch miedzy wersja 1 i 2, ktory zostanie nalozony
> na dokument uzytkownika. W rezultacie czesto moze sie zdarzyc, ze dany
> plik bedzie zupelnie poprawny. Jesli natomiast zmiany na serwerze i
> lokalnie sie zazebiaja, to CVS o tym informuje i zaznacza nakladajace
> sie fragmenty, ktore trzeba juz recznie skorygowac.
> 
> Po korekcie dokument można powtórnie commitnąć do archiwum. Teraz
> lokalne repozytorium użytkownika B ma zaznaczone, że dysponuje on już
> wersją numer 2 dokumentu zatem na serwerze zostanie zapisana wersja 3.
> 
> Jesli chodzi blokowanie dostepu - to tak jak juz napisalem wczesniej,
> oprocz lockow zakladanych na czas operacji commit i update mozna jeszcze
> blokowac dostep do plikow na czas edycji. Zapomnialem tylko napisac, ze
> to wymaga najpierw wlaczenia watchow na pewien zakres plikow. Wtedy przy
> updacie lokalne kopie plikow beda 'read-only'. Jesli ktos chce je sobie
> przeedytowac, to powinien uzyc cvs edit, dzieki czemu plik zostanie
> zablokowany na wylacznosc do czasu commita (lub unedita, ktory anuluje
> wprowadzone zmiany), a lokalna kopia dokumentu otrzyma prawa do edycji.
To tak jak SCCS? Z tym, ze tak mozna chyba tylko tak...
Nie wiedzialam, ze tak w CVS mozna (patrz: nie bawilam sie w dokladne
czytanie dokumentacji). W praktyce wlasciwie nigdy tego nie
uzywalismy. Na ogol jest tak, ze kazdy pracyje nad swoim kawalkiem i
rzadko sie zdarza, zeby komus zalezalo na blokowaniu dostepu do pliku.
Ale dobrze, ze cos takiego sie istnieje, jakby bylo potrzebne.

Ewa
 
> Michał
> 
> -- 
> WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
> add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *   POLAND
Technical Details
Message-ID: <199903112140.IAA12191@hulk.vic.design.telecom.com.au>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!ict.pwr.wroc.pl!m2n-gate.okapi.usenet.pl

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!ict.pwr.wroc.pl!m2n-gate.okapi.usenet.pl
From: emurawsk@vic.design.telstra.com.au (Ewa Murawska)
Newsgroups: pl.comp.objects
Subject: Re: CVS [było o UML]
Message-ID: <199903112140.IAA12191@hulk.vic.design.telecom.com.au>
Date: 11 Mar 99 21:52:07 GMT
Sender: objects@sprocket.ict.pwr.wroc.pl
Organization: Lista dyskusyjna objects@sprocket.ict.pwr.wroc.pl
Lines: 58
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit