Newsgroup: it.comp.os.linux.sys
Titolo: DRCS...quale?

Ciao,
Al momento uso svn, ma a volte rimango senza connessione al server,
quindi ho bisogno un sistema di controllo delle revisioni che mi
permette di lavorare anche quando non sono collegato al server.
Quindi pensavo di usarne uno distribuito, ma quale?
Ho googleato un po' e ho trovato:
- GIT
- Mercurial
- Bazaar
ma sembrano piu' o meno la stessa cosa. Cosa dovrebbe portarmi a
preferire uno piuttosto che l'altro (a parte il colore del logo)?
voi cosa usate? e perche'?
Grazie Ciao Jack

 Perche' e' lo standard sotto BSD e non usa un foxxuto database binario.
Bah, CVS fa schifo al cazzo se devi usarlo per qualcosa più complicato della 
gestione di 4 configurazioni (per inciso io per le configurazioni uso 
appunto cvs, peò se lo vuoi per programmare *almeno* subversion)
-- 
Vide

 voi cosa usate? e perche'?
Personalmente uso Mercurial sia perche` viene usato in progetti che
seguo, sia perche` ha un sistema di gestione che mi piace di piu` (git
e` modulare ed ha un sistema di gestione che trovo piu` confusionario,
mentre bazaar a parte ubuntu non lo usa nessuno)
Enrico

 voi cosa usate? e perche'?
mercurial, che non ho voglia di perdere tempo ad imparare ad usare uno 
strumento, preferisco uno strumento che si faccia usare subito :D

 Perche' e' lo standard sotto BSD e non usa un foxxuto database binario.
Al giorno d'oggi, l'unico motivo per usare CVS e` perche` si segue un
progetto che continua ad essere mantenuto con questo sistema. Se si deve
far partire un nuovo progetto allora molto meglio usare un VCS piu`
moderno e funzionare che un VCS antiquato come CVS. Da questo punto di
vista, Subversion risulta la scelta peggiore, mentre un DVCS risulta
quella migliore. A tal proposito, posto che tutti i sistemi VCS
hanno un comando per l'estrazione del log e per l'estrazione del
diff tra una revisione e l'altra, perche` dovrebbe essere meglio
utilizzare una struttura testuale piuttosto che un database per gestire
lo storico delle revisioni (considerando anche che e` la struttura piu`
comoda per gestire una tipologia di dati simile)[1]?
Enrico
[1] Personalmente penso che tu abbia in mente Subversion con l'utilizzo
di BerkeleyDB come backend. Tieni presente che tale sistema e` stato
abbandonato a favore di un backend a file system, in quanto BerkeleyDB
creava piu` problemi che mai (soprattutto a causa di lock che mettevano
a rischio il repository in caso il database fosse esportato su share
NFS), mentre i sistemi DVCS implementano vari sistemi per evitare il
problema (e.g. Monotone usa un database SQLite come backend), senza
contare che sono formati pubblici e documentati

 Ed usare dei server ridondanti invece?
ok, mea culpa.
La mancata connessione al server non capita perche' il server crasha,
ma perche' io sono in viaggio e non sempre ho una connessione a
internet.
Ciao Jack


ok grazie a tutti.
Ciao Jack

 quella migliore
Non sono del tutto d'accordo, considerando anche che il caso più comune è 
avere Subversion come repo ufficiale (da cui si estraggono le versioni) e un 
DVCS come "front-end" per gli sviluppatori, che poi fanno commit con 
strumenti appositi come git-svn.
-- 
Vide

 strumenti appositi come git-svn.
Mi sembra un controsenso, se devo avere un repository centrale allora
metto in piedi un albero con il DVCS che uso e dico a tutti "Quello e`
il server principale, potete partire da li per le modifiche" (e.g. i
miei progettini li gestisco con mercurial, che tengo centralizzati,
sempre con mercurial, sul serverino che ho in casa)
Enrico

 CVS.
Lo stato dell'arte, insomma.
Specie quando la richiesta dell'OP è quella di un sistema distribuito
che si possa usare offline.