Newsgroup: it.comp.os.linux.sys
Titolo: hg (mercurial): domanda facile..

domanda facile (per chi sa la risposta):
qual è il corrispondente di: cvs update ?
hg update mi risponde picche!
p.s.: ma è valsa la pena aver sviluppato tre tool differenti che fanno
all'incirca la stessa cosa? Non era meglio un cvs++, e niente svn,
niente hg?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 niente hg?
E git e bazaar dove li lasci?
È proprio questa la bellezza dell'open source, scegli te il tool che più 
ti piace.
-- 
"Mai sottostimare la larghezza di banda di un camioncino che sfreccia a
razzo sull'autostrada" 
Andrew S. Tanenbaum
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"

 ti piace.
Quella che tu chiami "bellezza" io la chiamo "perdita di tempo".
Soggettivo ovviamente... ma avrei trovato più conveniente -
dal punto di vista di impiego delle risorse - far avanzare il cvs,
aggiungendo le X funzioni, che lo avrebbero portato al livello per
portarlo  al livello degli altri sistemi.
Ma in fin dei conti come si fa l'update di un repo locale con HG? ^_^


 Ma in fin dei conti come si fa l'update di un repo locale con HG? ^_^
http://mercurial.selenic.com/wiki/TutorialCopia


 degli altri sistemi.
Quanti server di posta esistono? Sendmail, Exim, Postfix, Qmail e altri; 
eppure nessuno si lamenta, ognuno ha il suo preferito e usa quello :-)


 
CVS era praticamente non più manutenibile; per questo è nato Subversion.
Poi sono cominciati a venire i sistemi distribuiti, prima Darcs e poi a 
seguire Git e Mercurial, entrambi sviluppati con in mente la gestione del 
kernel di Linux, se ricordo bene.
Bazaar non so quando/come sia venuto fuori.
Ciao  Manlio

 Bazaar non so quando/come sia venuto fuori.
L'ha creato Canonical


 
hg pull -u 
http://blablabla


 eppure nessuno si lamenta, ognuno ha il suo preferito e usa quello :-)
anche questo è vero .... però è anche vero che avere diverse
implementazioni di sistemi di versioning è come avere diverse
implementazioni del comando 'cp'.
Cosa deve fare un sistema di versioning in fin dei conti? checkout,
commit, add remove ... ma c'era bisogno dopo 'svn' di sviluppare altri
n-mila progetti?


 n-mila progetti?
Se sono stati sviluppati e si sono diffusi evidentemente č perché c'era
spazio per quel prodotto.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 hg pull -u 
http://blablabla
Che equivale ad un "hg pull 
http://blablabla
;hg update"
Enrico

 niente hg?
No. 
Primo, CVS e` rimasto al palo a causa di una presunta retrocompatibilita` 
che, in alcuni casi, doveva essere necessariamente rotta per implementare 
determinate funzionalita`.
Secondo, perche`, se e` vero che CVS e SVN funzionano secondo uno schema 
client/server classico gestione centralizzata), e` vero anche che sistemi 
cone Git e Mercurial funzionano secondo lo schema in cui il client e` anche 
il server, in modo da accettare modifiche e propagarle verso gli altri 
(gestione distribuita).
Terzo, ma non meno importante, ti e` stato detto che i vari sistemi di 
controllo di versione hanno senso di esistere alla  stessa maniera dei vari 
MTA. Il paragone e` sbagliato. I vari sistemi di controllo di versione hanno 
lo stesso senso dei vari editor di testo (vorrei far notare la drammaticita` 
del paragone): ognuno ha il suo metodo di funzionamento, gestisce a modo suo 
il lavoro che si sta svolgendo, ha piu` o meno funzionalita` rispetto ad un 
altro editor di testo. Eppure fanno tutti la stessa cosa, ovvero 
visualizzare e modificare un file di testo
Enrico

 hg update mi risponde picche!
hg pull -u
che equivale a
hg pull && hg update
hg pull -> scarica i nuovi changeset
hg update [rev] -> aggiorna alla revisione rev (di default tip)
 > p.s.: ma è valsa la pena aver sviluppato tre tool differenti che fanno
 > all'incirca la stessa cosa? Non era meglio un cvs++, e niente svn,
 > niente hg?
si, visto che hg è l'unico decente con un'interfaccia umana (l'altro 
sarebbe git, ma ha un'interfaccia utente oscena)

 determinate funzionalita`.
]zac[
cvs è prodotto storico, e come al solito ognuno ci vede quel vuole (come con 
mysql), ci si vede solidità e affidabilità, ci si vede arretratezza e la 
mancanza delle funzionalità moderne assolutamente necessarie ( :P ) ...
svn è moderno, giovanile agile, scattante, pieno di nuove funzionalità, però 
facendo lo switch di versione parte del codice sorgente di kde più di 
qualche volta ha lasciato 'pezzi per strada', tanto che per sicurezza ho 
preferito rifare il checkout da zero.
git è un progetto piuttosto particolare, con quel suo gestire i repository 
non centralizzati, e sinceramente, se l'ha scelto linus (o meglio se sono 
fatti proprio per quello) per gestire lo sviluppo del kernel tenendo a bada 
la marea di codice e patch che gli arrivano ... io mi fido ..

 mi fido ..
Git non l'ha scelto Linus, l'ha scritto Linus... :)
Per il resto, io devo ancora farmi un'idea precisa di quale DVCS usare, 
ma senza la D io preferisco SVN a CVS. E`, senza ombra di dubbio, piu` 
veloce e stabile, e supporta meglio i binari.
Bye.

 Bye.
Concordo, svn è meglio, ha più funzioni.
Ma quanto a sicurezza nei cambi di versione (e in quei casi in cui si migra 
il codice per differenza (test di varie versioni, porting di modifiche tra i 
vari branch, ecc.)) cvs a me non ha mai dato il più piccolo segno di non 
aver eseguito il compito in maniera perfetta, svn invece qualche volta ha 
lasciato pezzi di codice anomali (non presenti o diversi facendo il checkout 
da zero).
In sintesi se devo imparare un nuovo sistema per usarlo nella gestione di 
progetti credo che preferirei ampiamente git (svn mi ha un po' deluso (come 
se fosse un server mail che ogni tanto perde qualche e-mail, lo considero 
inaccettabile)).

 la mancanza delle funzionalità moderne assolutamente necessarie ( :P ) ...
Beh, roba come il supporto ai commit atomici e alla rinominazione dei file 
non le vedo come "funzionalita` moderne assolutamente necessarie" :)
Semplicemente, CVS ha fatto il suo tempo e la scelta logica sarebbe di 
sostituirlo con CVSNT ma, a questo punto, diventa piu` logico usare 
Subversion o un DVCS
Enrico

 Semplicemente, CVS ha fatto il suo tempo e la scelta logica sarebbe di
]zac[
Concordo.
Però anche senza quelle funzionalità, che per altro non sono di uso 
frequente, si riesce comunque a gestire i progetti, mentre il potersi 
totalmente affidare che le azioni richieste sul codice siano sempre 
''perfettamente'' eseguite fanno parte del cuore del programma, e cvs non mi 
ha mai dato la più piccola seccatura, mentre svn, come scritto nel mio post 
precedente, qualche volta mi ha irritato (e nel momento sbagliato (come 
sempre succede), mentre stavo provando una cosa nuova e che non compilava 
per problemi per me contorti e misteriosi).

 diversi facendo il checkout da zero).
Li sto usando in parallelo da qualche anno (cvs al lavoro dove era gia` 
presente, svn per progetti privati).
Mi e` capitato qualche volta che cadesse la connessione con entrambi, e 
cvs mi lasciava il commit o l'update a meta`, svn no.
Inoltre ho avuto l'impressione che svn fosse piu` furbo a gestire i merge 
(cvs tende piu` spesso a creare conflitti), ma non era lo stesso codice, 
quindi potrebbero essere stati casi particolari.
 
Con nessuno dei due ho avuto perdite di pezzi di codice, tranne quando ho 
fatto una cazzata io (ho copiato una directory con relativa subdir CVS, e 
quando committavo le modifiche alla copia sovrascrivevo anche 
l'originale...)
Bye.