Newsgroup: it.comp.java
Titolo: sistema di controllo delle revisioni

secondo voi qual'è il miglior sistema di controllo delle revisioni?
Svn?
 
ambiente java/eclipse/tomcat
ad es
 
ciao, Jasmine

 ad es
 
l'ambiente non dice nulla. quello che conta è la metodologia di
sviluppo che utilizzate nel vostro gruppo di lavoro. svn con il suo
chiaro sistema di gestione revisioni "per commit" è quello più
tranquillo e che fa fare meno casini, mentre git e mercurial risultano
più "spinti" verso metodologie agili.
 

 ad es
 
Uh? e questo come dovrebbe incidere nella valutazione di un VCS?
 
-- 
SoulSpirit

pi� "spinti" verso metodologie agili.
 
 
thanks
 
 
ciao, Jasmine
--
 
Wataya Noboru non doveva difendere nulla.Per questo 
poteva concentrare tutti i suoi sforzi nella conduzione
pura e semplice della battaglia. 
L'uccello che girava le viti del mondo,Murakami Haruki

Uh? e questo come dovrebbe incidere nella valutazione di un VCS?
 
 
non per valutarne le funzionalità
solamente relativamente a configurazione
 
già che ci sono approfitto per chiedere un'altra cosa
ho trovato poco cercando in rete:
Per quanto riguarda i Continous Integration Systems
sapreste dirmi (magari con qualche esempio in rapporto
al n di progetti) minimum requirements hardware
e utilizzo della ram, con 
 Hudson, Jenkins e CruiseControl
(magari se c' qualcosa di "meglio" sempre free)
 
thanks, Jasmine


 Svn?
 
La tua domanda e` portatrice di flame :)
 
Scegliere un VCS equivale alla scelta di un editor di testo: ognuno ha le 
sue preferenze, ogni strumento ha i suoi pro, ogni strumento ha i suoi 
contro. Tenendo presente queste considerazioni, proviamo a fare una analisi 
critica ed obiettiva. In primis c'e` da considerare anche la metodologia di 
lavoro che si intende utilizzare. Ad esempio, se si vuole un ambiente 
centralizzato, dove tutti i repository sono gestiti da un unico server le 
modifiche devono *necessariamente* finire solamente su di esso, Subversion 
e` la scelta indicata. Di contro, Subversion e` lento nelle operazioni su 
grossi repository[1] (e con grossi intendo con centinaia di migliaia di 
file) nonche` invasivo[1] (crea una directory .svn in ogni directory del 
repository), senza contare che alcune funzionalita` sono necessariamente da 
emulare a mano (e.g. il branching, che dev'essere fatto con un svn copy). 
Git e Mercurial, oltre ad essere piu` veloci[2] e meno invasivi, di contro 
adottano un approccio distribuito, ovvero ogni repository fa allo stesso 
tempo da server e da client (ambiente distribuito), permettendo quindi la 
condivisione diretta tra gli utenti (ovvero, non si passa necessariamente 
dal server). Questo approccio e` ovviamente piu` flessibile, in quanto 
permette di avere un workflow semplice (come quello di Subversion) o 
workflow piu` complessi (e.g. sul server principale puo` fare commit solo il 
project manager). Di contro (ed e` questo il vero problema di un DVCS) e` 
molto piu` semplice perdersi le modifiche, ovvero ci si puo` ritrovare nella 
situazione che un utente o non permette il pull (scaricamento da terzi), o 
non esegue il push (invio a terzi) delle proprie modifiche[3].Per quanto 
riguarda l'integrazione con prodotti di terze parti, Subversion la fa da 
padrone, soprattutto per il fatto che e` quello con piu` anni "di servizio". 
C'e` comunque da dire che la popolarita` di Git e di Mercurial si e` 
ampliata esponenzialmente con gli anni, di conseguenza anche loro li trovi 
integrati con molti prodotti di terzi. Per una comparativa migliore e per 
vedere anche altri nomi, puoi vedere qui: 
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
 
 
Enrico
[1] "Caratteristiche" che dovrebbero essere state limate nella versione 1.7 
di Subversion (di certo so della sparizione delle directory .svn)
[2] Non tanto Mercurial, sicuramente Git
[3] Per Mercurial l'impatto e` mitigato in quanto e` possibile configurare 
l'autopush delle modifiche, per Git penso sia possibile ma non ne so molto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJO9Nh3AAoJED3SMOGZLYdYo10H/RBD82ZJCZdm6cx10nQkGNbg
MW2B1uYn+FW2OlZfu21zJgVWbvxeyBxmuIu8g2aPenltX2xDVq3KT/dd8U5gzs/7
+/x1/c/59m34PhEUZaWvgM637JQ0cvjPRyeBCcJjfxMQouMEkEzudZ/R9btCmeNE
TRza0tbSonO8AKtoZJWIZNODwUUgpp9VZ1FN6N08npDdgwCQtOvj8TZKZx+dn3FY
Jc+q9usVMkRgHGYeaCpn5MUD5axgkdu+bc2Tvao6jDhwzStcmcQ35s1ptwrtpPP9
kWz2BbFLyYDpxOviTfMPfgjtG/SZNhGDmDRn3oJH65ypAUuarD5qlZRhqrqRWjs=
=6n9Q
-----END PGP SIGNATURE-----
 

 tempo da server e da client (ambiente distribuito)
[...]
 
Quello che tu descrivi come svantaggio obiettivo, io lo considero un forte vantaggio obiettivo:
Pur essendo distribuiti, nulla ti vieta di mantenere comunque un server, un repository centrale e anzi ti permette di inventarti architetture su misura che un tipico sistema client/server non consente. A questa possibilita' si aggiunge quella di poter committare (in locale) e pullare/pushare (in remoto) pur non avendo la momentanea possibilita' di collegarsi al repository centrale.
 
Ci sono un sacco di altri vantaggi derivanti dall'architettura distruibuita, tra cui il fatto che ogni utente ha accesso in locale a tutta la history del progetto (quindi maggiore velocita' e sicurezza), che e' possibile eliminare completamente una commit eseguita oppure crearsi un branch locale che potra' poi essere condiviso con gli altri oppure no.
 
-- 
SoulSpirit

La tua domanda e` portatrice di flame :)
 
non era assolutamente nelle mie intenzioni, anzi!
Sto facendo una ricerca 

Sei stato molto esaustivo, grazie davvero
e a questo punto auguri di Buon Natale (domani :o))
a te e al ng
 
ciao, Jasmine
 
 
- -
°
 °* Nel futuro regno magico di Calendarmen ogni giorno sorge illogico a Calendarmen
     sta scoppiando una battaglia molto strana sono in guerra i giorni della settimana
      la malvagia e nera principessa Lunedi usurpare vuole il posto di sovrano a Domenica
        la vera erede al trono
 
 

 comunque un server, un repository centrale
 
Infatti lo specifico piu` avanti :)
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJO9crzAAoJED3SMOGZLYdYkVUH/0vzkIo0iwbtQimjlg9Mjw4i
6zb4YtfiZqEnxvXUD7V3zQV4xl4Ym6LooB9+K7kqjpJaC+W8JTVjcVdFLixXHy9f
wiVyM60XmeL4sYz5Av1cbMGjsSsCbKJHGijv8ejKSdKkxwAE+5lof5YN9Q6nSLd5
fPnEK662jimsV3ybx7WtIE57ni3aZuV2Uco61nin4FwR0ZfjmZ0bh9vXR7xLFFCH
X9YGSJkk7BjgjFcZARXh7GJhJHWNXV/xN4sCQSjSRfvrbUhqUbvVANf9ZDJ8h8ui
c1zeoOHu0Xk9CKnFY1qocmQFheU2I7L1HAEfo4I76nO8ZS15Bkhm+xvyjkFtkP0=
=E+YB
-----END PGP SIGNATURE-----
 

 
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
 
 
Dissento pure qua. cosa manca a Mercurial o git? Entrambi hanno 
tortoise, entrambi hanno plugin di ogni tipo per Eclipse, in piu' hanno 
i miglior hosting remoti sul mercato (non a pagamento), e un infitnià di 
estensioni. Io direi che quello peggio supportato oggi e SVN, non certo 
Git, Mercurial.

 Git, Mercurial.
 
Io direi che tu abbia usato Mercurial o Git solo in casi comuni e con un 
workflow semplice, quando gli unici due motivi per usarli in quel contesto 
sono la comodita` di utilizzare uno strumento che si conosce (che potrebbe 
essere decisamente un ottimo motivo per il 90% delle scelte) e la 
possibilita` di poter mutare il workflow nel futuro (caso che potrebbe non 
presentarsi mai)
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJO+GDAAAoJED3SMOGZLYdYs/IH/j8q5I2yNoLcvh7w4smTkxrs
R0UCkrW73H9V5Wi0IMF+uNVFk/S0M0g4dnDAtafNlrMz22x9zhcCUfMWCsaxCkCD
Ryb65qBsrMbw8K0KIx9lTKaN+95vruQ25iRd0JQNMeclfQgdHJyWL1kttYxfFOvg
ws0lEvn+A7d2GJISUjOaTgQIDtixloYo0SySZC6wjSMK8IDbX+aE8dJ0/guW2P2l
h06sdupZhW1uGkXJHCRGre4UnOXj2sJvI8lMkWB7WIdQKDLjJXeboD04L9mxe1t2
6AZIUehw3BcxwyvWSPq0Wz+VF3BsbLe/edGNmeApRnuKlybABHK67M2MPgk7RbU=
=AquP
-----END PGP SIGNATURE-----
 

 presentarsi mai)
 
E dici cose false.

 -svn nel caso un team necessiti un repository di riferimento.
 
Perche`, sostanzialmente, e` questo il loro funzionamento. La vera 
differenza sta tutta sulle tipologie di workflow che i due strumenti ti 
permettono di gestire. Per fare un confronto, e` come parlare del comando 
unix sed: esso sostanzialmente permette di fare delle manipolazioni ad uno 
stream di testo (Stream EDitor) ma cio` non toglie che possa essere 
utilizzato in un contesto completamente differente da quello originale (e.g. 
io lo uso spesso per rinominare un gruppo di file). Per quanto riguarda gli 
strumenti a disposizione, dubito fortemente che un prodotto uscito nel 2005, 
per quanto famoso esso sia, abbia piu` strumenti integrabili (e non parlo 
solo di quelli messi a disposizione dalla comunita`) rispetto ad un prodotto 
uscito nel 1990 e considerato per almeno 10 anni (nel 2000 e` uscito 
Subversion) lo standard de facto tra i sistemi di SCM in circolazione. 
Infine, la complessita` di un progetto non e` una cosa che si decide a 
priori. Per fare un esempio, la complessita` di una libreria che prende i 
dati da IMDB e li mostra all'utente sotto forma di oggetto e` nota, meno 
nota e` la complessita` di un software che la sfrutti per catalogare una 
collezione di film posseduti.
 
Detto questo, ritengo doveroso fare un appunto (piu` o meno) fuori contesto. 
Ho valutato parecchio se rispondere o meno al tuo post, soprattutto 
considerando i toni da fanboy e al limite del troll da te utilizzati. Il mio 
intento nel thread e` sempre stato specificare *cosa* e` un determinato 
software e *come* e` possibile sfruttarlo in un particolare contesto, 
valutando i pro ed i contro di tutti e due gli approcci. Il tuo discorso era 
invece incentrato su come un sistema e` meglio di un altro (palesemente 
falso, visto che ogni cosa ha il suo ambito di utilizzo) non accettando 
critiche (rimaste da parte mia *sempre* applicabili ad un discorso generico) 
alle tue opinioni. A questo punto mi viene da darti un consiglio: se non sei 
pronto a confrontare le tue idee con quelle di qualcun altro o non sei 
pronto a capire il senso di una discussione, evita di rispondere, ne 
gioverai in salute
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJPE1vuAAoJED3SMOGZLYdYhl8H/RjilVr/yXP9OqS8wa+HH8Qc
ZpE/sYWmDmbMQlBzp8ivPAAKp+1edrDYjyTWEskLAxIbSgWquDSVw6MH30gkPDnD
oDins0zC5jIwYOrGlUI4E1VfRcOlDRUIYVFDB1wIEL/e25f+gEBv+pgNbTVOpc1h
UTfjncHg+vbweHNUlS63K34T36VC5WPa1uaCE24QPB07CdfBBEcmnJipj6G0JZ18
QisFakdjmaS0PpUOc9ccvFnxhT6zaHwZkztmpxp11tdgfn485yAG/XWKNL81bdny
p1oBW3XilRI1eZxW1P4f32wd5yqlycBk7deYCA+IoROlFfD3NOBjSVl/odMR6go=
=t96Y
-----END PGP SIGNATURE-----
 

 Enrico
 
Ahah, io sto benissimo. Fidati :)