Gestire le modifiche a un progetto Rails con Bazaar e Olive

Diamo uno sguardo a Bazaar (il VCS di Ubuntu) e a come utilizzarlo per gestire un progetto fatto con Ruby on Rails.

Bazaar

Si tratta di uno strumento molto utile per gestire le modifiche fatte ai file (VCS) e le sue caratteristiche principali sono l'essere:

  • distribuito: si possono apportare delle modifiche a un progetto altrui e gestire le revisioni come se si fosse proprietari.
  • integrato: si integra con Nautilus ed è estensibile con dei plugin
  • semplice: viene utilizzato anche da chi usa un'altro VCS (es SVN) per fare delle modifiche locali


Riunificazione di 2 rami locali: myapp e myapp.experimental

Installazione

Potete installarlo selezionando bzr e bzr-gtk da Synaptic o con

apt-get install bzr bzr-gtk

Se volete avere le ultime versioni disponibili aggiungete questo repository

deb http://bazaar-vcs.org/releases/debs/feisty ./

Iniziamo

Per chi non lo sapesse un progetto Rails non contiene solo codice sorgente, ma anche file di configurazione, file temporanei, database, che ovviamente non vogliamo tener traccia nel VCS.
Questo utilizzo potrebbe sembrare specifico, ma problematiche molto simili sono comuni a molti altri contesti.

rails myapp
cd myapp
bzr init      # Crea la cartella .bzr
bzr add       # Aggiunge ricorsivamente i file presenti
script/server # Parte il server Rails, CTRL+C
bzr status    # Vengono creati dei nuovi file "inaspettati"
...
unknown:
  config/lighttpd.conf
  log/fastcgi.crash.log
  log/lighttpd.access.log
  log/lighttpd.error.log
  tmp/cache/index.html-gzip-627926-7552-1183916515
..

Per ignorare questi ed altri file, la via migliore è creare un file .bzrignore così:

gedit .bzrignore
config/database.yml
config/lighttpd.conf
log/*.log
tmp/cache/*
tmp/pids/*
tmp/sessions/*
tmp/sockets/*
db/*.db       # Nel caso usiate un db SQLite
db/schema.rb  # Verrà generato in seguito
vendor/rails  # Se utilizzate Rails Edge

Esiste anche il comando bzr ignore <parametri>, ma ve lo sconsiglio perché crea doppioni e confusione. Modificate direttamente .bzrignore e controllate che i file vengano ignorati.
bzr ignored # e/o che non ci siano in bzr status

Una volta controllato che non ci sia spazzatura siete pronti a fare il commit, in questo caso il primo.

bzr commit -m 'First commit'

Procedete in questo modo, per tutte le modifiche che fate al codice, magari aggiornando il file .bzrignore all'occorrenza.

script/generate controller pages
bzr add
bzr commit -m 'Aggiunto controller pages'
added app/controllers/pages_controller.rb
added app/helpers/pages_helper.rb
added app/views/pages
added test/functional/pages_controller_test.rb
Committed revision 2.

Se non vi appassiona digitare tutte le volte i comandi potete utilizzare anche l'ottima GUI Olive.
Sempre tramite l'intefaccia grafica potete gestire con una facilità disarmante diversi rami sperimentali per per poi unirli in seguito.
Per esempio potete provare a fare creare un nuovo ramo (push), fare delle modifiche nel nuovo ramo e reimportarle(merge) in quello ufficiale.


Annotate, per vedere le modifiche fatte sul file in che ramo e da chi


In caso di rami in conflitto usate meld (apt-get install meld) per sistemare il file

Altre considerazioni su Bazaar e Rails e Capistrano

commenti

VCS centralizzati contro distribuiti


Si tratta di uno strumento molto utile per gestire le modifiche fatte ai file (VCS) e le sue caratteristiche principali sono l'essere:
* distribuito: si possono apportare delle modifiche a un progetto altrui e gestire le revisioni come se si fosse proprietari.

Ritenendo la tua definizione poco chiara mi permetto di fare delle precisazioni:

  1. In informatica, il controllo versione è la gestione di versioni multiple di un insieme di informazioni su cui può lavorare un gruppo di persone (http://it.wikipedia.org/wiki/Controllo_versione): è quindi implicita la possibilità di apportare modifiche a un progetto altrui e gestire le revisioni;
  2. Strumenti di questo tipo possono essere distinti in base a 2 macro-categorie: centralizzati e distribuiti

Per farla breve:

  1. VCS centralizzati hanno un'architettura di tipo client/server: unico repository centrale; working directory sui client; commit/update tra client e server; (es. SVN-SubVersioN, CVS)
  2. VCS distribuiti hanno un'architettura di tipo p2p: ogni nodo ospita contemporaneamente repository e working directory; commit/update locali; (es. DARCS, Bazaar, Git, Mercurial-hg)

Spero di essere stato chiaro e soprattutto di aiuto...

IsMaEl

@Anonymous

MI sono recentemente interessato a VCS distribuiti leggendo varie documentazioni e manuali. E soprattutto qualcosa che sia più malleabile di CVS nella gestione dei branch....

Mi sembra di capire però che gli unici che abbiano una integrazione sotto windows siano solo CVS e SVN, tramite i tortoise*. La linea di comando non mi spaventa e anzi, per alcune cose, la uso sotto linux.....

Ho installato HG in attesa di poterlo provare... Ho visto che esiste questo bazaar ma non ho approfondito la conoscenza.

Mi interesserebbe scambiare alcuni pareri ed esperienze, se sei disponibile.

Francesco

Definizioni

Il mio intento era per lo più quello di presentare Bazaar come prodotto funzionante per tutti out-of-the-box (non solo programmatori), quindi ho tralasciato molti termini specifici e teoria.
In compenso ho linkato la tabella comparativa su Wikipedia.
Grazie comunque del commento, chi già conosce qualche altro VCS riuscirà ad inquadrare meglio l'articolo.