erlug
[Top] [All Lists]

Re: [Erlug] necessito ragguagli su (?)CVS(?)

To: erlug@xxxxxxxxxxxxxx
Subject: Re: [Erlug] necessito ragguagli su (?)CVS(?)
From: Claudio Cicali <c.cicali@xxxxxxxxx>
Date: Wed, 21 Jul 2004 22:46:40 +0200
Sythos wrote:

Consiglio subversion:


che succede se dato il file originale "pippo.ext" due persone ne creano
ognuno una evoluzione?

Sia CVS che SVN (subversion) gestiscono questo tipo di conflitti.
Subversion li gestisce meglio:
tutti e due hanno meccanismi che permettono di risolvere automaticamente
i conflitti. I conflitti però sono di due specie: quelli indolori e
quelli dolorosi. I conflitti indolori sono quelli che risolvibili,
ovvero quando vengono modificate parti DIVERSE del file. In questo
caso l'intelligenza dello strumento è sufficiente per generare una
versione "pippo.ext" sana, da poter mettere nel repository centrale
con tutta tranquillità. I conflitti dolorosi sono quelli che invece
si hanno quando le due versioni modificate collidono sulle STESSE
righe di codice. In questi casi sia CVS che SVN ti avvertono:
"ragazzo, non ce la posso fare: avete fatto casino, sistemate la
faccenda". Tutti e due sono carini e ti dicono anche DOVE è il
problema. Il fatto è che te lo dicono MODIFICANDO il file originale:
     ">>>> EHI, QUI C'E` UN CONFLITTO INSANABILE <<<<<<"
a questo punto, ecco la differenza: CVS ti permette di salvare sul
repository centrale (operazione di "commit"), la versione contenente
la stringa
     ">>>> EHI, QUI C'E` UN CONFLITTO INSANABILE <<<<<<"
(succede, perché i conflitti ti vengono segnalati, ma le operazioni
vanno avanti lo stesso. Può capitare di non farci caso)
Subversion NON ti permette di fare commit di versioni di file con
conflitti.
Oltretutto, sempre sui conflitti, svn e` piu` elegante. A fronte di
di un impossibile "merge", ti vengono scaricati la versione piu'
nuova, la versione comune non modificata e ti viene rinominata la
versione che hai tu in locale. In questo modo hai tutti i dati
necessari alla risoluzione del problema.


e' possibile lanciare uno script ogni qualvolta che qualcuno carica un
file modificato?

Con CVS quasi, con SVN sempre.
Mi spiego:
una delle piu` grosse pecche di cvs (gia` questo un motivo per
abbandonarlo) è quella di non aver il commit "atomico".
Metti che io modifico 10 file, ne cancello 4 e ne creo 6.
Metti che faccio il mio bel commit per portare queste belle cose
sul repository centrale.
Metti anche che mentre cvs sta aggiornando il 5 file dei 10
modificati, mi si spegne il client (la signora delle pulizie, con
la scopa). Brutta storia: cvs _HA_ aggiornato quei 5 sul repository
centrale, ma ha perso le altre modifiche. La risoluzione del
problema a questo punto sta nella tua a) fortuna b) confidenza con
il cvs c) speranza che nessuno, nel mentre, non cerchi di fare
un aggiornamento della sua copia locale con meta` delle tue
modifiche d) etc...
SVN ha i commit atomici: TUTTE le operazioni di commit necessarie
o le fa tutte o non ne fa nessuna. Per cui parti sempre da una
situazione SANA.
E c'e` un'altra questione, legata appunto agli script.
Premesso che cvs ha il supporto a script da lanciare dopo che un
commit e` terminato, quello che ho sempre desiderato fare era
fare un aggiornamento di una copia del progetto sul server di test:
faccio le mie modifiche in locale, le provo e vanno bene, faccio
il commit. Bene, il commit dovrebbe anche aggiornare la macchina
di test in maniera che tutti possano provare la nuova versione.
Ebbene, con cvs non si può fare (in maniera semplice e 'naturale'):
come dicevo prima, il cvs non ha commit atomici, e come conseguenza
di questo non puoi lanciare operazione CVS sullo stesso repository
durante... un'operazione cvs sullo stesso repository. Dunque non
puoi fare un update (o una export) del repository sul quale stai
facendo commit, perché sebbene lo script di post-commit sia stato
"triggerato" (urgh), il commit stesso non è terminato... un bel
casino.
Nessun problema del genere con SVN, e ho finalmente potuto
implementare il svn update alla fine di qualsiasi commit.



il tutto dovrebbe avere modo che anche da un client win si possa operare

Turtqualcosa, come gia` succerito e` un fighissimo client svn.
Wincvs o vari ambaradan plugin di eclipse o compagnia belli
esistono anche per cvs.

consigli?

Subversion.

Altri vantaggi (possibilità di muovere/cancellare directory, cosa
che il cvs non sa fare, semplicità di amministrazione, semplicità
di gestione dei branches, storia delle copie e delle move... etc)
sono lunghi da spiegare, e mi sono già dilungato abbastanza.

Ciao
--
  Claudio Cicali
  http://www.flexer.it

<Prev in Thread] Current Thread [Next in Thread>