svn appunti guida html.it

Dump e restore

svnadmin dump /home/svn/progetto/ > progetto.dump 
svnadmin create --pre-1.4-compatible progetto
svnadmin load /home/svn/nas/repos/progetto < progetto.dump ;

oppure per repository meno vecchi

svnadmin create --pre-1.5-compatible sira

Sintassi e appunti veloci per l'uso di subversion lato client riassunto della guida di html.it

La guida di riferimento è Guida html.it

checkout di cartelle

di una cartella, in questo caso abbiamo un repository http

svn checkout http://repository/local/work/path
checkout di singoli file
svn checkout http://svn-vd.devel/repos/guidasvn/indice.txt

attenzione a non effettuare checkout successivi sulla stessa cartella, in caso contrario avremo la certezza di rovinare completamente la nostra copia di lavoro. Il comando giusto per aggiornare la nostra copia locale è svn update, che vedremo nella prossima lezione.
cartella .svn

Si tratta della cartella che contiene le informazioni sull'aggiornamento. Tra le altre cose, vengono qui conservate le copie "originali" dei file (cioè quelle scaricate con l'ultimo checkout o update) che il client usa come confronto per rilevare le modifiche effettuate localmente; nonché le informazioni sulla revisione scaricata e sulla data e ora dell'ultimo update.

comandi vari
    * svn add
    * svn delete
    * svn copy
    * svn move

se usiamo svn move il file si porta lo storico dietro, se lo spostiamo manualmente alla commit svn vedrà solo l'eliminazione di un file da una cartella e la creazione di un file in un altra. Inoltre l'operazione di move potrà essere annullata
commit
svn commit  --message "Messaggio di log" /local/path

La commit specificando il path viene applicata solo alla cartella indicata, se non viene specificata si usa la cartella locale. E' obbligatorio specificare un messaggio di commit oltre che altamente consigliabile scriverlo comprensibile.
update
svn update

Va inoltre lanciato prima di effettuare un commit, per evitare l'errore out-of-date: questo messaggio indica che qualcun altro ha modificato e caricato sul server un file dopo che noi l'abbiamo scaricato l'ultima volta sul nostro PC, per cui la nostra copia “originale” (quella nascosta) non è più aggiornata. Con un update portiamo in locale le ultime modifiche (verificando anche eventuali conflitti) e poi potremo procedere al commit.

revisioni

La revisione si applica a tutto l'albero: si tratta di una istantanea del contenuto dei file ma anche del loro nome, della loro posizione, e delle cartelle esistenti.
Si possono effettuare le operazioni sulle revisioni con l'opzione -r

svn checkout -r <numero_revisione>
svn update -r <numero_revisione>
Nomi di revisioni

Esistono anche della parole chiave per indicare revisioni "speciali":

  • HEAD, indica l'ultima revisione presente nel repository. È la revisione implicitamente utilizzata quando non ne viene specificata una
  • BASE, indica la revisione "originale" presente sulla propria copia di lavoro. Non si riferisce al server, ma solo alla copia locale; non include eventuali modifiche locali effettuate nel frattempo
  • COMMITTED, indica l'ultima revisione uguale o precedente a BASE, nella quale un oggetto è stato modificato. Si riferisce quindi sempre alla copia di lavoro locale: permette sostanzialmente di identificare la revisione creata con l'ultimo commit andato a buon fine
  • PREV, indica la revisione immediatamente precedente a COMMITTED
revisione con la data

usare la seguente sintassi

--revision {"2008-07-11 19:00"}
--revision {2008-07-11}
--revision {19:00}

se si specifica una data senza specificare l'ora (es. —revision {2008-07-11}) SVN considera come orario 00:00 e quindi, di fatto, considera le revisioni registrate fino al giorno prima (nell'esempio, fino al 10 lug alle 23:59).
Per esaminare temporaneamente una diversa revisione, dobbiamo ricordare di effettuare checkout in una cartella diversa rispetto a quella che ospita la nostra copia di lavoro corrente. Creiamo quindi una copia di lavoro temporanea che, una volta esaminata, possiamo tranquillamente cancellare.

Lavorare sullo storico

svn log -r 5:9

mostra i log delle revisioni dalla 5 alla 9 (incluse). Se usando questo comando si riceve un log vuoto, dobbiamo assicurarci di essere nella cartella principale del progetto e non in una sottocartella.
svn diff -r 5:6 nomefile

ci mostra un confronto tra la versione 5 e la 6 del file indicato.
svn diff -r 5

Se specifichiamo una sola revisione, viene effettuato un confronto tra la nostra copia di lavoro e la revisione indicata.

In TortoiseSVN, il comando svn log è diventato l'opzione show log, che mostra l'elenco delle revisioni disponibili. Se eseguiamo questo comando su uno specifico file, possiamo poi selezionare due tra le revisioni mostrate, cliccare con il tasto destro e selezionare l'opzione compare revisions per eseguire l'equivalente del comando svn diff.

Risolvere i conflitti

…………. continuare da qui …………

Gestione avanzata dei progetti

I rami (branches)

Un ramo nasce semplicemente come copia del progetto principale. I diversi rami rimangono comunque in qualche modo collegati, infatti è possibile trasportare le modifiche da un ramo all'altro o addirittura fondere completamente due o più rami.
I motivi che portano all'uso dei rami sono tipicamente due:

  1. La creazione di diverse versioni dello stesso progetto,
  2. La creazione di un ambiente di sviluppo temporaneo, destinato prima o poi a essere fuso con il ramo principale

Creazione di un ramo

Per convenzione, la cartella del ramo principale viene chiamata trunk e la cartella dedicata ai rami viene tipicamente chiamata branches
Per creare un ramo separato, va usato il comando svn copy:

svn copy URL1 URL2 -m "Messaggio"

per esempio
svn copy http://svn.vd-devel/repos/guidasvn/trunk http://svn.vd-devel/repos/guidasvn/branches/sistemisti -m "Creazione ramo separato sistemisti"

Per Subversion non esiste realmente il concetto di rami separati: se creiamo una copia di una cartella, per lui è semplicemente questo: la copia di una cartella. Siamo noi che, potendo fare checkout, update e commit di singole cartelle del repository, lo consideriamo un ramo separato e lavoriamo solo su quello.
Come tutti gli elementi copiati – condividono lo storico fino al momento della copia.
Trattandosi sempre di uno stesso repository, inoltre, la numerazione delle revisioni rimane comune tra i rami: ad esempio se effettuiamo un commit sul ramo principale e generiamo la revisione 10, il commit successivo sul ramo secondario produrrà la revisione 11.

Spostare un repository già creato

svn move URL1 URL2

Con TortoiseSVN, possiamo avviare il Repository Browser e utilizzare l'opzione Create folder per creare la struttura che ci interessa, e poi trascinare direttamente con il mouse i file già esistenti nella nuova locazione.
Questa operazione non richiede particolare attenzione per essere effettuata, ma è fondamentale che tutti gli utenti ne siano informati. La copia di lavoro locale infatti non può sapere di questo spostamento (che tramite il Repository Browser viene effettuato direttamente sul server) e quindi va aggiornata utilizzando il comando relocate che ci permette di specificare il nuovo URL. In alternativa, si può semplicemente eliminare e ricreare la copia di lavoro.

Unire i cambiamenti

svn merge http://svn.vd-devel/guidasvn/trunk

Esegue esattamente questo: verifica che l'URL che stiamo chiedendo NON sia quello da cui abbiamo fatto il checkout ma ne è una copia; risale quindi all'ultima revisione in comune tra le due copie; rileva i cambiamenti effettuati a partire da quella revisione e li applica alla nostra copia locale, segnalandoci eventuali conflitti.

Il comando merge è piuttosto potente. Tutto quello che dobbiamo fare noi è assicurarci, prima di eseguirlo, che tutti i cambiamenti locali sulla nostra copia di lavoro siano stati caricati con un commit sul ramo corrispondente (cioè il ramo secondario) e dopo l'esecuzione, esaminare con calma le modifiche apportate (col comando svn diff).

Attenzione, però: per adesso l'unione delle modifiche è limitato alla copia di lavoro locale: quando avremo risolto i conflitti e verificate tutte le modifiche, dovremo effettuare il commit dei cambiamenti per sincronizzare definitivamente i due rami.

Ricordiamo che per Subversion i rami sono normali cartelle, quindi possono avere associate delle proprietà (dette anche metadati). Il comando merge sfrutta questa possibilità per salvare una proprietà mergeinfo che verrà esaminata nei successivi merge, per evitare di riportare più volte gli stessi cambiamenti.

Quindi invocando in seguito lo stesso comando usato per la prima sincronizzazione verranno uniti solo i cambiamenti successivi.

Gestione progetti

Uno degli script che ho usato per importare un progetto che precedentemente avevo scaricato sulla macchina.

svnadmin create /opt/svn-rep/$1
svn import /root/svn-tmp/$1 file:///opt/svn-rep/$1
chown -R giuseppe:svn-a /opt/svn-rep/$1
chmod -R 770 /opt/svn-rep/$1

Un'altro script usato per prelevare e pulire i progetti svn

svn co file:///opt/svn-rep/$1
cd $1
for lib in $(find . -name .svn); do rm -rf $lib; done
cd ..
scp -r $1 root@149.7.211.235:/root/svn-tmp

Riunificazione dei rami

bellissima guida
Ne ho rubacchiato qualche pezzo per paura che andasse off-line

(branch nel lessico di subversion) con il ramo trunk del repository.

utilizzare il comando merge con lo scopo di fondere due rami del repository.

* branches (contiene copie del codice contenuto in trunk usate per lo sviluppo di nuove funzionalità o per la correzione di errori, di solito queste copie alla fine del processo di sviluppo vengono fuse con il codice contenuto in trunk)
* tags (contiene copie del codice contenuto in trunk, ad esempio: versioni stabili)
* trunk (il punto principale di sviluppo dell’applicazione)

Per effettuare la fusione dobbiamo, prima di tutto, controllare il numero di revisione in cui abbiamo ramificato il nostro progetto con il comando:

svn log --verbose --stop-on-copy http://svn.example.com/repos/project/branch/my-project

L’ultima revisione stampata da questo comando è il numero di revisione da cui dobbiamo partire per fare la fusione (ad esempio: 354).

Per applicare la fusione posizioniamoci nella nostra working copy (checkout aggiornato del ramo trunk dell’applicazione) e lanciamo il comando:

svn merge -r354:HEAD http://svn.example.com/repos/project/branch/my-project

Questo comando applica al ramo trunk le modifiche apportate nel ramo privato. A questo punto potremmo trovarci di fronte a conflitti nella fusione del codice, in questo caso svn ci da la possibilità di controllare le differenze, editare online il file, risolvere i conflitti o postporli a revisioni successive.

Lanciamo il comando svn st per analizzare le modifiche apportate dalla fusione e, dopo aver fatto tutte le verifiche del caso (compilazione, esecuzione tests, ecc…), rendiamo permanenti le modifiche con il comando svn ci. Nel messaggio della revisione teniamo nota dei numeri di revisione fusi, ad esempio se l’ultima revisione del ramo trunk è la 562 scriviamo nel messaggio: “Merged my-project-branch changes 354:562 into the trunk”, in questo modo se il lavoro di sviluppo sul branch my-project dovesse continuare potremo riassorbirlo in seguito nel ramo trunk partendo dalla revisione 562 e non dalla 354 (prima revisione dove esiste il nostro ramo privato).

Per maggiori informazioni:

* Chapter 4. Branching and Merging – http://svnbook.red-bean.com/en/1.0/ch04s04.html

Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License