Article View: pl.comp.objects
Article #5044Re: CVS [było o UML]
From: Michal Mosiewicz
Date: Tue, 09 Mar 1999 23:16
Date: Tue, 09 Mar 1999 23:16
43 lines
3204 bytes
3204 bytes
Piotr Piatkowski wrote: > [...] > 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. Hmm - ja np. nigdy nie pracuję na wielu plikach jednocześnie, jeśli nie mam pewności, że ktoś inny też ich nie zacznie zmieniać. A nic nie stoi na przeszkodzie, żeby zalockować wszystko. Zważ, że locking w CVSie nie tylko jest zakładany na czas commit/update, ale również na czas edycji pliku. Często się pracuje bez lockowania plików. Natomiast zawsze, jeśli chcesz zabezpieczyć sobie jakis zestaw plikow na czas edycji to masz cvs edit/unedit. Powyższa sytuacja też raczej nie zachodzi, jeśli aktualizacje robi się hurtem bo wtedy locki są zakładane na całe moduły. Oczywiście jeśli ktoś będzie wkładał plik po pliku, to owszem - może się zdarzyć, że archiwum będzie niespójne. W skrajnym przypadku ktoś przy załadowaniu nowej wersji pliku dostanie ostrzeżenie, że nie dało się jej bezbólowo połączyć z wersją w repozytorium i będzie musiał ręcznie skorygować pliki (które zawierają wtedy dwie wersje kodu) i powtórnie je commit-nąć. W gruncie rzeczy właściwe działanie CVS-a uwarunkowane jest rozsądkiem ludzi, którzy z niego korzystają. Jeśli np. ktoś robi jakieś eksperymenty nad większym modułem, to dobrze jest zrobić dla modułu forka i podłączyć jego zmienioną wersję do głównego pnia dopiero jak wiadomo, że wszystko jest już OK. Poza tym CVS ma jeszcze sporo dodatkowych mechanizmów do obserwowania tego, co się w nim dzieje i pod warunkiem, że ekipa umie go używać, to raczej nie ma żadnych problemów. Follow-up: pl.comp.programming (bo to bardziej tam się powinno znaleźć) 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:
<36E5ABB2.FA45462C@interdata.com.pl>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!polsl.gliwice.pl!news.task.gda.pl!mimo.lodz.pdi.net!not-for-mailReferences:
<199903090425.PAA16098@kaos.vic.design.telecom.com.au> <7c3q1o$h2e$1@druid.ceti.com.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!polsl.gliwice.pl!news.task.gda.pl!mimo.lodz.pdi.net!not-for-mail From: Michal Mosiewicz <mimo@interdata.com.pl> Newsgroups: pl.comp.objects,pl.comp.programming Subject: Re: CVS [było o UML] Followup-To: pl.comp.programming Date: Wed, 10 Mar 1999 00:16:02 +0100 Organization: Interdata s.c., http://www.interdata.com.pl Lines: 43 Message-ID: <36E5ABB2.FA45462C@interdata.com.pl> References: <199903090425.PAA16098@kaos.vic.design.telecom.com.au> <7c3q1o$h2e$1@druid.ceti.com.pl> NNTP-Posting-Host: mimo.lodz.pdi.net Mime-Version: 1.0 X-Trace: korweta.task.gda.pl 921021679 7962 195.116.162.218 (9 Mar 1999 23:21:19 GMT) X-Complaints-To: abuse@task.gda.pl NNTP-Posting-Date: 9 Mar 1999 23:21:19 GMT X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.1 i586) X-Accept-Language: pl,en-US,en Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit