Drupal.org si sposterà da CVS a GIT

Probabilmente molti di voi sapranno che il vcs (=version control system) di drupal.org cambierà da CVS a GIT. I principali promotori dell'esodo (come l'hanno chiamato durante la presentazione al Drupalcon SF2010) sono la prezzemolinica webchick e Sam Boyer, che hanno spinto per cambiare radicalmente e dire finalmente il controllo versioni dell'oramai iper-obsoleto CVS.

La decisione non è stata presa con leggerezza, come dimostrano le pagine wiki e le discussioni riguardo alla migrazione.

Il repository GIT in modalità read-only lo potete trovare su http://git.drupal.org mentre la documentazione su GIT e le tre FASI della migrazione sono rispettivamente sul Prototype Git book (tree isolato dal resto della doc) e sul Community Initiatives Doc.

Buon GIT e buona ricerca del tool adatto.

Scusa la domanda forse

Scusa la domanda forse banale, questo cosa comporta per l'utilizzatore medio di Drupal (lato web-developer)?

Balbo wrote:Scusa la domanda

Balbo wrote:
Scusa la domanda forse banale, questo cosa comporta per l'utilizzatore medio di Drupal (lato web-developer)?

Se mi fai questa domanda, probabilmente niente :)

Non sempre la brevità è un

Non sempre la brevità è un virtù...

Psicomante wrote:
Balbo wrote:
Scusa la domanda forse banale, questo cosa comporta per l'utilizzatore medio di Drupal (lato web-developer)?

Se mi fai questa domanda, probabilmente niente :)

Personalmente penso che lo sviluppatore web medio (grafico, programmatore, ecc) dovrebbe sapere cos'è un version control system, a cosa serve, e perchè rende la vita più facile.
Cos'è: Controllo versione
A cosa serve: Come utilizzare CVS sulle Linux
Perchè rende la vita più semplice?

  • Tengo tutto il codice, immagine, file, ecc di un sito in un unico posto
  • Posso vedere chi ha modificato cosa (anche riga per riga per file di testo)
  • Posso tornare indietro ad una precedente versione, poi riprendere la versione attuale
  • Ogni modifica (o insieme di modifiche) viene registrato - anche con messaggi - nel log
  • I could go on...

Libri (inglese, spiacente):

P.S. se qualcuno ha dei link a documenti un pò meno 'asciutto' fateci sapere...

Più imparo, più dubito.

Si hai ragione John, grazie

Si hai ragione John, grazie per le precisazioni che hai inserito. Continuo con i link

http://it.wikipedia.org/wiki/Concurrent_Versions_System spiegazione di cos'è CVS e la sua storia
http://it.wikipedia.org/wiki/Repository cos'è il repository dei sorgenti.

http://it.wikipedia.org/wiki/Git_%28software%29 il sistema che Drupal.org userà

altre alternative a GIT
http://en.wikipedia.org/wiki/Mercurial
http://en.wikipedia.org/wiki/Bazaar_%28software%29
http://it.wikipedia.org/wiki/Subversion

Il tutto mi fa pensare che

Il tutto mi fa pensare che con John e Psicomante siamo messi bene utilizzando Drupal.
Grazie.

:-/ La mia domanda non era

:-/

La mia domanda non era "cos'è un version control system"! Uso regolarmente SubVersion per i miei lavori e più o meno credo di sapere che cosa fa... La mia curiosità era per sapere a grandi linee cosa avrebbe comportato per drupal passare da CVS a GIT (vantaggi? eventuali svantaggi). Cmq grazie dei vari link, appena ho un po' di tempo ci darò certamente una letta.
Ciao

http://www.ibm.com/developerw

Più imparo, più dubito.

Aggiungerei che oltre ad

Aggiungerei che oltre ad essere distribuito (cosa non da poco, considerando che si ha un progetto gestito da genete sparpagliata in giro per il mondo) è molto (MOOOOLTO) più veloce di CVS e SVN, inoltre (come mi capita spesso di dire) permette di avere un approccio diverso alla gestione del commit, permettendo ad ogniuno di fare tutti i branch nel suo repository locale, e poi mergiare (in maniera semplice e abbastanza affidabile) il tutto nel ramo principale.

Questo permetterebbe di "ristrutturare" il workflow di lavorazione rendendo teoricamente più veloce il processo di commit (e quindi di rilascio) delle diverse funzionalità.

Ciao
Marco
--
My blog
Working at @agavee

@mavimo E' veloce proprio

@mavimo

E' veloce proprio perchè è distribuito :). SVN e gli altri richiedono accesso al server per fare le operazioni; GIT invece permette di eseguirle localmente e poi fondere remotamente. Per questo è rapido.

Poi a differenza di CVS e SVN, GIT (ma credo anche HG e BZR) gestisce i contenuti non i file. Permette quindi di spostare, dividere, fondere agilmente i file.

No, è proprio più veloce,

No, è proprio più veloce, perchè si basa sugli hash delle cartelle e non sui contenuti dei file, anche in locale SVN è più lento (tanto che quando Linus decise di partire con lo sviluppo di GIT lo fece proprio a causa della lentezza del sistema di revision che stavano usando sul kernel all'epoca).

In ogni caso il fatto di essere distribuito rende il tutto ancora più veloce (per le operazioni in locale).

Non capisco invece la seconda affermazione:

Psicomante wrote:

Poi a differenza di CVS e SVN, GIT (ma credo anche HG e BZR) gestisce i contenuti non i file.

Ciao
Marco
--
My blog
Working at @agavee

nel senso che mentre CVS e

nel senso che mentre CVS e SVN usano la codifica delta sui file per memorizzare le differenza GIT non lo fa. Inoltre CVS per identifica l'albero delle versioni di un file usava il suo nome, cosa che crea problemi nel caso si debba rinominare un file (si perde l'intera storia!).

GIT da quanto ho capito lavora sull'hash tree dell'intero progetto (o più probabilmente su una serie di hash tree). Comunque non è vero che GIT è sempre più veloce; lo è in molti casi. Sarebbe inverosimile altrimenti.

Non mi è mai capitato di

Non mi è mai capitato di avere situazioni in cui GIT è più lento di SVN, puoi farmi qualche esempio?

Ciao
Marco
--
My blog
Working at @agavee