Appunti per l`uso di Bazaar

Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
autori: luciano de falco alfano
Sommario
Sommario......................................................................................................................................................1
Introduzione: i VCS......................................................................................................................................1
A cosa servono......................................................................................................................2
Come si utilizzano..................................................................................................................2
Concetti generali..........................................................................................................................................3
Installazione..................................................................................................................................................4
I principali comandi......................................................................................................................................4
Aiuto (help).............................................................................................................................4
Identificazione (whoami)........................................................................................................5
Inizializzazione (init-repo, init).............................................................................................5
Gestione dei file (add, remove).............................................................................................6
Controllo della revisione (commit, uncommit, revert, info, log, status, diff)......................7
Inizializzazione, operazioni avanzate (branch, checkout, merge, resolve)..........................9
Riassumendo........................................................................................................................12
Lavorare in modalità centralizzata (lockstep)...........................................................................................13
Creazione di un repository centrale condiviso (init-repo)................................................13
Creazione di un branch centrale e suo popolamento (init, push, pull, checkout, bind,
unbind)..................................................................................................................................14
Lavorare con i checkout (update, commit, commit --local, bind, unbind)........................16
Cenni per lavorare in modalità distribuita.................................................................................................19
Inserimento di una nuova funzione nel trunk senza amministratore.................................20
Inserimento di una nuova funzione nel trunk con amministratore.....................................20
Appendici....................................................................................................................................................21
Gestione del “warning some compiled extensions could not be loaded”..........................21
Utenza e password per il “file schema” in Windows non funzionano...............................21
Riferimenti..................................................................................................................................................21
Acronimi e abbreviazioni...........................................................................................................................22
Identificazione e storia del documento.....................................................................................................22
Queste note illustrano alcuni concetti generali relativi all'uso dei sistemi di
versioning, e le operazioni di base per l'utilizzo di uno di essi: Bazaar.
Per maggiori informazioni
documentazione relativa a
letteratura su Internet.
riguardo questi argomenti si può utilizzare la
Bazaar (rif.[3] a pag.21) o consultare l'estesa
Introduzione: i VCS
Bazaar appartiene alla famiglia di programmi noti come Version Control Systems
(VCS).
I VCS sono anche detti: Revision control systems, source control systems, o
Fname: bazaar_note-1.1
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
software configuration management (SCM) systems.
Oltre Bazaar, altri noti esponenti dei VCS sono Concurrent Version System (CVS)
e Apache Subversion (SVN). Ma sono solo alcuni esempi: di VCS ne esistono
veramente una pletora.
A cosa servono
A che serve un VCS?
Il suo scopo consiste nel permettere di memorizzare in un determinato istante lo
stato di un insieme di file. E di poter ottenere in un momento successivo il gruppo
di file che formano uno degli stati salvati. E' una sorta di undo, ma con due
prerogative:
•
lavora con gruppi di file invece di un file singolo;
•
è possibile ottenere non solo l'ultimo gruppo di file salvati, ma anche un
qualunque gruppo precedente.
In questo modo, ad esempio, è possibile:
•
buttare tutto e ricominciare da capo se si sono fatti errori estesi nella
stesura di più file che formano il gruppo di documenti di un progetto;
•
clonare un progetto in sviluppo, effettuare delle modifiche per studiare un
determinato concetto, e successivamente decidere se inglobarle nel
progetto originale;
•
clonare un progetto in sviluppo tante volte quanti sono i programmatori
incaricati,
e
successivamente
riportare
gli
sviluppi
effettuati
autonomamente da ciascuno di loro nel progetto di riferimento.
Questi sono solo alcuni esempi di utilizzo.
Come si utilizzano
E' facile definire cosa fa un VCS. Ma le modalità di utilizzo possono essere molto
diverse.
I VCS possono essere utilizzati da una sola persona. Ad esempio per tenere la
storia di una documentazione complessa, formata da più sorgenti (disegni, tabelle
e altre componenti assemblate in un documento faldone).
Oppure possono essere utilizzati da gruppi di programmatori, magari posti in sedi
molto distanti fra loro, che devono collaborare a uno stesso progetto di sviluppo
software.
Bazaar a questo riguardo è molto flessibile. Permette di adottare sia i due modelli
di lavoro predetti, che altri casi intermedi.
Questa flessibilità di Bazaar introduce un elemento di complessità da tenere sotto
controllo.
Pag. 2 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Concetti generali
Per utilizzare Bazaar (e altri sistemi VCS) è necessario avere ben presenti i
seguenti punti.
•
Revision, o revisione. E' una istantanea dei file su cui si sta lavorando. E'
possibile ottenere una copia dell'insieme dei file che formano una revisione.
•
Working tree, o albero di lavoro. E' la directory in cui sono i file e le
subdirectory sotto controllo da parte di Bazaar.
•
Branch, o ramo, o linea di sviluppo. E' la storia delle revisioni che formano
l'evoluzione dei file su cui si lavora. Quindi un insieme (temporalmente)
ordinato di revisioni. Un progetto può avere linee di sviluppo parallele.
Quando questo accade, linee di sviluppo con un antenato comune sono dette
related branches. Quando una linea di sviluppo confluisce in un'altra, si
applicano i cambiamenti della prima alla seconda. Questo tipo di operazione
è detta merge.
•
Repository è un magazzino di revisioni.
e Branch sono associati 1:1. Deve
esistere 1 un Working tree per un determinato
branch , e viceversa.
Working Tree
Un esempio di evoluzione di un gruppo di file è
rappresentato nella figura a fianco, ripresa da
wikipedia .
Nella figura, i quadrati numerati sono revisioni. I
nodi verdi rappresentano la linea di sviluppo
principale. Quelli arancioni sono le copie di lavoro,
che poi saranno fatte confluire nella linea di sviluppo
principale con operazioni di fusione (merge).
Quando si lavora con un VCS, di solito si ha a che
fare con questi tipi di operazioni:
Illustrazione 1:
Esempio di evoluzione
di un gruppo di file (da
Wikipedia)
•
inizializzazione di un repository con un dato
progetto;
•
estrazione di una propria copia di lavoro del
progetto dal repository;
•
effettuare il lavoro sulla propria copia,
eventualmente fissando delle revisioni; si noti
che in questa fase, oltre modificare, è
possibile aggiungere/togliere file/directory
dal progetto;
•
far confluire il lavoro effettuato dalla propria
copia alla linea di sviluppo di riferimento nel
1 In questo ambito, Bazaar ammette eccezioni, come spiegato successivamente a pag.5.
Pag. 3 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
repository.
Questo processo di lavorazione è valido anche per Bazaar.
Un punto cui fare attenzione è il concetto di repository. Con Bazaar è possibile
fare a meno del repository, e lavorare direttamente utilizzando il solo concetto di
branch. Ma un repository, soprattutto se condiviso tra i branch 2 , permette una
flessibilità (e complessità) nettamente superiore.
Installazione
Dal sito , effettuare il download della versione 2.1.1 che si basa su python 2.6 (file
bzr-2.1.1.win32-py2.6.exe ).
Installazione standard.
Check:
bzr --version
Bazaar (bzr) 2.1.1
Python interpreter: C:\Programmi\Python26\python.exe 2.6.2
Python standard library: C:\Programmi\Python26\lib
Platform: Windows-XP-5.1.2600-SP3
bzrlib: C:\Programmi\Python26\lib\site-packages\bzrlib
...
I principali comandi
In questo capitolo vediamo i principali comandi di Bazaar. Per la cronaca: sono
meno di 20.
Aiuto (help)
Il comando principale è help . Quando si conoscono i principi di base, l'uso
dell'help spesso risolve eventuali dubbi.
Il solo help elenca i comandi conosciuti da Bazaar.
E' possibile richiedere help comando per avere la descrizione sintetica del
comando cercato.
Esempi di uso di help
Elenco dei comandi disponibili:
bzr help
Bazaar 2.1.1 -- a free distributed version-control tool
http://bazaar-vcs.org/
Basic commands:
bzr init
bzr branch
bzr add
bzr ignore
bzr mv
makes this directory a versioned branch
make a copy of another branch
make files or directories versioned
ignore a file or pattern
move or rename a versioned file
2 Rimarchiamo il concetto. In Bazaar, per condiviso, si intende tra branch; non tra utenti.
Pag. 4 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
bzr status
bzr diff
summarize changes in working copy
show detailed diffs
bzr merge
bzr commit
bzr send
pull in changes from another branch
save some or all changes
send changes via email
bzr log
bzr check
show history of changes
validate storage
bzr help init
bzr help commands
bzr help topics
more help on e.g. init command
list all commands
list all help topics
Help relativo ad un singolo comando, ad es. add (si veda oltre):
bzr help add
Purpose: Add specified files or directories.
Usage:
bzr add [FILE...]
Options:
--dry-run
-v, --verbose
--file-ids-from=ARG
--no-recurse
-q, --quiet
--usage
-h, --help
Show what would be done, but don't actually do
anything.
Display more information.
Lookup file ids from this tree.
Don't recursively add the contents of directories.
Only display errors and warnings.
Show usage message and options.
Show help message.
Description:
In non-recursive mode, all the named items are added, regardless
of whether they were previously ignored. A warning is given if
any of the named files are already versioned.
...
Identificazione (whoami)
Con i sistemi di versioning è necessario identificarsi. Con Bazaar si usa il comando
whoami . Ad esempio:
bzr whoami "user <casella-postale@dominio>"
definisce l'utente user con email casella-postale@dominio . Virgolette e parentesi
acute vanno usate letteralmente.
L'identificazione deve essere effettuata una volta sola. Non è una login per una
singola sessione di lavoro.
Inizializzazione (init-repo, init)
Abbiamo:
•
init-repository , o init-repo , inizializza un repository vuoto su una
directory;
•
init , inizializza un branch vuoto su una directory.
Se esiste un repository condiviso tra più branch, deve essere posizionato nella
directory padre dei working-tree dei diversi branch.
Quando si usa la init su una directory, se nella directory padre vi è un repository,
la storia del branch e relative revisioni sono registrate nel repository. In caso
contrario, Bazaar registra la storia e le revisioni stesse nel DB del branch.
Pag. 5 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Il comando init-repo ha l'opzione --no-trees per creare un repository i cui
branch sono di default senza working-tree. Ovvero esistono come directory, ma
non hanno una copia locale del codice. Questo è utile per i repository centralizzati.
Permette di creare branch i cui working tree sono remoti, localizzati sui computer
degli sviluppatori.
Esempio: creazione di un repository locale
Supponiamo di avere questa struttura locale:
C:/.../sviluppo
+---- sito
+---
files del sito: html e css
Dove sito è la directory di lavoro corrente per lo sviluppo di un sito.
Vogliamo mettere il progetto sotto controllo di versione. Per farlo, prevediamo un
repository condiviso (directory .../sviluppo/repo ), e sotto questo le directory
per
i
branch.
In
particolare
per
il
main
branch,
che
chiamiamo
.../sviluppo/repo/sito . Alla fine avremo:
C:\...\sviluppo
+--- sito
# dir.di lavoro corrente
|
+--- files del sito: html e css
+--- repo
# dir.del repository
+--- sito # dir.del main branch
Questa struttura può essere creata con i comandi
(1). . . .cd .../sviluppo
bzr init-repo repo
Shared repository with trees (format: 2a)
Location:
shared repository: repo
cd repo
bzr init sito
Created a repository tree (format: 2a)
Using shared repository: C:/.../sviluppo/repo/
In questo caso il repository nella directory .../sviluppo/repo conterrà la storia
di .../sviluppo/repo/sito . Così come le varie revisioni create.
Se si vuole creare un branch vuoto parallelo in .../sviluppo/repo/sito-b1 , basta
eseguire:
cd .../sviluppo/repo
bzr init sito-b1
Gestione dei file (add, remove)
Con repository e branch vuoti ci si fa poco.
A questo punto dobbiamo gestire il contenuto di una revision, nonché la sua
creazione. Per la creazione si veda il paragrafo successivo (controllo della
versione). Per la gestione dei file abbiamo i seguenti comandi.
•
add , registra file/directory da incamerare alla prossima revisione.
•
remove --keep , deregistra file/directory dalla revisione. Attenzione: questo
Pag. 6 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
comando è pericoloso. Senza l'opzione –-keep , non solo rimuove il file dal
DB di Bazaar, ma anche dal disco su cui si sta lavorando.
Esempio: registrare file in un repository locale
Supponiamo di avere creato il repository locale dell'esempio (1) (pag.6).
Vogliamo aggiungere al progetto i file che abbiamo gestito in .../sviluppi/sito .
Per farlo li copiamo nella directory .../sviluppi/repo/sito e poi li registriamo
per la prossima revision:
(3). . . .cd .../sviluppi/repo/sito
copy ../../sito/*.* .
..\..\sito\index.html
..\..\sito\page_1.html
..\..\sito\page_2.html
..\..\sito\test.css
4 file copiati.
bzr add
adding index.html
adding page_1.html
adding page_2.html
adding test.css
La copy porta nella directory corrente (che è la linea di sviluppo principale) i file
che stavamo precedentemente editando. Il comando add senza ulteriori parametri
indica a Bazaar di aggiungere al controllo di versione tutti i file e sottodirectory
che trovano nella directory corrente.
Controllo della revisione (commit, uncommit, revert, info, log, status, diff)
A questo punto dobbiamo gestire la versione (revision), con i seguenti comandi.
•
commit , crea la revisione;
•
uncommit , rimuove l'ultima revisione;
•
revert , riporta i file del branch corrente all'ultima revisione salvata;
•
•
info , visualizza le informazioni
working tree, repository o branch;
(localizzazioni
e
formati)
riguardanti
log , elenca le revisioni presenti nel branch;
•
status , elenca
revisione;
i
file
correnti
modificati/aggiunti/rimossi
rispetto
la
•
diff , individua le differenze tra i file correnti e quelli che formano l'ultima
revisione.
Esempio: creare una revisione, editing errato dei sorgenti, ripristino dei sorgenti
Supponiamo di avere preparato l'ambiente dell'esempio (3) (pag.7).
Siamo pronti per creare una revisione:
(4). . . .cd .../sviluppi/repo/sito
bzr commit -m "primo snapshot"
Committing to: C:/.../sviluppo/repo/sito/
added index.html
Pag. 7 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
added page_1.html
added page_2.html
added test.css
Committed revision 1.
L'opzione -m (message) di commit , serve per commentare lo snapshot.
Se si modificano i file di progetto, usando nuovamente il comando commit si creerà
un secondo snapshot. E così via.
La situazione del repository, dopo la commit sarà la seguente:
bzr log
-----------------------------------------------------------revno: 1
committer: ldfa <[email protected]>
branch nick: sito
timestamp: Tue 2010-05-04 19:39:59 +0200
message:
primo snapshot
Ipotizziamo di modificare pesantemente il codice, e di realizzare di avere fatto
errori diffusi non accettabili.
Controlliamo con uno status :
bzr status
removed:
page_2.html
modified:
index.html
page_1.html
Osserviamo un file rimosso, e altri due modificati. Modificati come? Facciamo diff.
>bzr diff
=== modified file 'index.html'
--- index.html 2010-05-04 17:39:59 +0000
+++ index.html 2010-05-04 22:33:37 +0000
@@ -1,11 +1,10 @@
<html>
<link rel="stylesheet" type="text/css" href="./test.css">
<body><h1>Home</h1>
<p>Welcome home</p>
+
<p> home</p>
<p>You have a lot of possibilities here:</p>
<ul>
<li><a href="./page_1.html">page_1 is here</a></p>
<li><a href="./page_1.html">and page_2 here</a></p>
</ul>
</body>
</html>
=== modified file 'page_1.html'
--- page_1.html 2010-05-04 17:39:59 +0000
+++ page_1.html 2010-05-04 22:34:17 +0000
@@ -1,5 +1,4 @@
<html>
<body><h1>WEB site page 1</h1>
<p><a href="./index.html">Home is here</a></p>
</body>
</html>
=== removed file 'page_2.html'
--- page_2.html 2010-05-04 17:39:59 +0000
+++ page_2.html 1970-01-01 00:00:00 +0000
@@ -1,5 +0,0 @@
-<html>
<body><h1>WEB site page 2/h1>
<p><a href="./index.html">Home is here</a></p>
Pag. 8 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
</body>
-</html>
Nel nuovo sito abbiamo perso il link alla home; la pagina rimossa la vogliamo di
nuovo. Ferma tutto: facciamo un restore dell'ultima revisione salvata.
bzr
M
M
N
bzr
revert
index.html
page_1.html
page_2.html
status
come si vede index.html e page_1.html vengono modificati; page_2.html è nuovo.
Il successivo controllo di stato è vuoto: nessuna differenza rispetto l'ultima
revisione.
Inizializzazione, operazioni avanzate (branch, checkout, merge, resolve)
Esistono altre due possibilità di inizializzazione da tenere ben presenti:
•
branch , crea una copia completa (inclusa la storia) di un branch; le due
copie sono indipendenti: una commit nella nuova copia non crea una
revisione nel branch sorgente;
•
checkout , crea una copia di lavoro di un branch esistente; le due copie
sono legate: una commit nella copia di lavoro crea l'analoga revisione
anche nel branch da cui si proviene.
Quando si creano copie di un working tree è perché si ha la necessità di lavorare
in parallelo, cercando di non aggrovigliare le modifiche effettuate per motivi
diversi. In questi casi, prima o poi, sarà necessario far confluire le modifiche
effettuate in un branch destinazione su quello di origine. A questo scopo si usa:
•
merge , permette di far confluire le modifiche effettuate in un branch, su
un altro branch; lavora con sorgenti che sono stati sottoposti a commit ;
•
update , effettua un allineamento dei sorgenti del branch corrente
(tipicamente: un branch destinazione) a partire dal branch sorgente 3 ;
•
resolve , per indicare a Bazaar che si sono risolti dei conflitti generati a
seguito di attività di merge / update.
Quando si fanno dei merge, può essere necessario gestire conflitti tra file
analoghi. Bazaar usa un criterio di merge intuitivo: un file modificato in uno solo
dei due branch è valido , invece un file modificato in entrambi i branch è un
conflitto da risolvere. Per darci modo di analizzare la situazione, Bazaar crea tre
nuovi file per ogni singolo file in conflitto:
•
nomefile .BASE , file della revisione precedente;
•
nomefile .OTHER , file proveniente dal branch che si vuole inglobare;
•
nomefile .THIS , il file bel branch corrente.
Inoltre in nomefile abbiamo la segnalazione di aggiunte nell'albero del branch
3 Il comando update è analogo al comando branch, ma tipicamente viene effettuato per mantenere
l'ambiente di lavoro corrente aggiornato rispetto una linea di sviluppo principale.
Pag. 9 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
( <<<<<<< TREE ) e di aggiunte richieste dal merge ( >>>>>>> MERGE-SOURCE ). I
conflitti così segnalati andranno risolti manualmente in nomefile , senza toccare i
file .BASE , .OTHER e .THIS . Dopo di che il comando resolve provvede alla loro
eliminazione e a spegnere il segnale di conflitto in corso.
Esempio: creazione di un branch di test, modifica e successivo merge
Supponiamo di avere pronto il main branch dell'esempio (4) (pag.7).
Per fare dei test d'uso dei css vogliamo farne una copia per evitare di farci editing
sopra:
cd ...\sviluppi\repo
bzr branch sito test-css
Branched 1 revision(s).
Nella directory test-css modifichiamo il css, creiamo la nuova revisione e poi
controlliamo la storia di questo branch e di quello da cui veniamo:
cd test-css
... modifica del css ...
bzr commit -m "h1 nero su rosso"
Committing to: C:/.../sviluppo/repo/test-css/
modified test.css
Committed revision 2.
(5). . . .bzr log
-----------------------------------------------------------revno: 2
committer: luciano <luciano@pc-marco-home>
branch nick: test-css
timestamp: Wed 2010-05-05 01:11:33 +0200
message:
h1 nero su rosso
-----------------------------------------------------------revno: 1
committer: ldfa <[email protected]>
branch nick: sito
timestamp: Tue 2010-05-04 19:39:59 +0200
message:
primo snapshot
cd ..\sito
(6). . . .bzr log
-----------------------------------------------------------revno: 1
committer: ldfa <[email protected]>
branch nick: sito
timestamp: Tue 2010-05-04 19:39:59 +0200
message:
primo snapshot
Un confronto tra i risultati dei comandi di log ai precedenti punti (5) e (6)
permette di osservare che in test-css ora abbiamo 2 revisioni, mentre la sorgente
sito ha una sola revisione.
Diciamo che le modifiche effettuate nel branch test-css ci piacciono; le vogliamo
inglobare nel main branch sito . Visto che abbiamo appena effettuato una commit
di test-css possiamo proseguire con il merge:
cd ...\repo\sito
bzr merge ../test-css
M test.css
All changes applied successfully.
Da notare che il merge non ha creato una nuova revisione in sito . E' sempre
necessario provare adeguatamente il nuovo codice prima di fare commit ! Per
Pag. 10 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
questo il commit deve esse chiamato esplicitamente in un secondo momento.
bzr log
-----------------------------------------------------------revno: 1
committer: ldfa <[email protected]>
branch nick: sito
timestamp: Tue 2010-05-04 19:39:59 +0200
message:
primo snapshot
Come si vede siamo ancora a revisione 1. Facciamo i nostri controlli, e poi
eseguiamo commit . Ora andremo alla revisione 2.
(7). . . .bzr commit -m "merged h1 nero su rosso"
Committing to: C:/.../sviluppo/repo/sito/
modified test.css
Committed revision 2.
Esempio: un merge con conflitto
Proseguendo l'esempio (7) (pag.11), abbiamo questa situazione iniziale:
cd .../sviluppo/repo/sito
bzr status
bzr info
Repository tree (format: 2a)
Location:
shared repository: C:/.../sviluppo/repo
repository branch: .
Related branches:
submit branch: C:/.../sviluppo/repo/test-css
Modifichiamo test.css sia su test-css che su sito , inoltre facciamo commit nei
due ambienti:
cd .../repo/test-css
... modifiche a test.css e ../sito/test.css ...
bzr commit -m "h3 nero su rosso"
Committing to: C:/.../sviluppo/repo/test-css/
modified test.css
Committed revision 3.
cd .../repo/sito
bzr commit -m "h2 nero su rosso"
Committing to: C:/.../sviluppo/repo/sito/
modified test.css
Committed revision 3.
Fin qui non ci sono problemi: i due branch sono del tutto indipendenti. Ora
facciamo il merge di test-css su sito :
bzr merge ../test-css
M test.css
Text conflict in test.css
1 conflicts encountered.
bzr status
modified:
test.css
unknown:
test.css.BASE
test.css.OTHER
test.css.THIS
conflicts:
Text conflict in test.css
pending merge tips: (use -v to see all merge revisions)
ldfa 2010-05-05 h3 nero su rosso
Abbiamo un conflitto in test.css .
Pag. 11 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Come detto, per darci tutte le informazioni necessarie all'analisi del conflitto,
Bazaar crea tre nuovi file:
•
test.css.BASE , file della revisione precedente;
•
t est.css.OTHER , file proveniente dal branch che si vuole inglobare;
•
test.css.THIS , il file bel branch corrente.
Inoltre in test.css Bazaar segnala le aggiunte nell'albero del branch ( <<<<<<<
TREE ) e le aggiunte richieste dal merge ( >>>>>>> MERGE-SOURCE ):
type test.css
h1 {color: black; background:red}
<<<<<<< TREE
h2 {color: black; background:red}
=======
h3 {color: black; background:red}
>>>>>>> MERGE-SOURCE
Editiamo il file per inglobare entrambe le modifiche, quindi indichiamo a Bazaar
che il conflitto è risolto, controlliamo lo stato e facciamo commit :
type test.css
h1 {color: black; background:red}
h2 {color: black; background:red}
h3 {color: black; background:red}
bzr resolve –-all
bzr status
modified:
test.css
pending merge tips: (use -v to see all merge revisions)
ldfa 2010-05-05 h3 nero su rosso
bzr commit -m "h1&2&3 nero su rosso"
Committing to: C:/.../sviluppo/repo/sito/
modified test.css
Committed revision 4.
Riassumendo
In sintesi, Bazaar mette a disposizione le seguenti funzioni:
•
whoami per identificarsi, da usare una sola volta;
•
init-repo e init per creare shared repository e branch vuoti;
•
add , remove --keep per registrare/deregistrare file e directory;
•
commit , uncommit per creare/cancellare revisioni;
•
revert , per ripristinare i sorgenti ad una certa revisione;
•
info , log , status , diff per controllare la situazione dei sorgenti rispetto
le revisioni;
•
branch , merge , resolve per copiare un branch esistente creandone uno
nuovo, per portare le modifiche operate in un branch su un altro, per
abbattere la segnalazione di conflitti risolti;
•
checkout per creare una copia di lavoro da un branch esistente, i due
branch sono legati (la commit su uno lavora anche sull'altro).
Esistono altri comandi che possono essere utili. Ad esempio la possibilità di
Pag. 12 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
assegnare etichette a una revisione (comando tag ). O la possibilità di estrarre un
package, ovvero tutti i sorgenti di un progetto inseriti in un archivio (comando
export ).
Per gli approfondimenti del caso riguardi i comandi illustrati e gli altri disponibili
si rimanda alla documentazione di utente (rif.[5] a pag.21).
Lavorare in modalità centralizzata (lockstep)
Ora che abbiamo visto il set di comandi base di Bazaar, fissiamo le linee guida da
seguire per un suo uso come sistema di gestione di un repository centrale.
In questo capitolo descriviamo il lavoro in modalità centralizzata; in letteratura:
lockstep .
In questo caso tutti i programmatori hanno una copia di lavoro del software, ma
ogni commit avviene verso un repository centrale.
Una commit non avviene se vi sono conflitti (analoghi a quanto descritto nel
capitolo Esempio: un merge con conflitto a pag.11).
Questo comportamento costringe chi programma a mantenere continuamente
allineata la propria copia di lavoro e risolvere i conflitti per effettuare la commit.
In generale le attività saranno:
•
creazione di un repository centrale condiviso;
•
caricamento dei sorgenti nel repository centrale;
•
collegamento dei branch locali;
•
upgrade e commit delle attività locali.
Creazione di un repository centrale condiviso (init-repo)
Sappiamo che un repository vuoto si crea con il comando init-repo .
Nel caso di repository centrali condivisi, di solito si usa init-repo --no-trees
per evitare di duplicare sul server dei working trees che in realtà hanno senso
solo in periferia. In questi casi si deve usare il comando checkout per legare il
working tree periferico a quello “dummy” centrale sul server.
Esempio: creazione di un repository condiviso e centralizzato
Supponiamo di voler creare un repository condiviso e centralizzato nel server
all'IP 10.10.7.249, che condivide la directory //10.10.7.249/Repository/ 4 .
Il
repository
che
noi
vogliamo
creare
sarà
nella
directory
//10.10.7.249/Repository/sviluppi .
(2). . . .bzr init-repo --no-trees file://10.10.7.249/Repository/sviluppi
Shared repository (format: 2a)
4 Non ci si faccia confondere dal fatto che il nome (Repository) della directory condivisa
di //10.10.7.249 coincide con il concetto di repository di Bazaar. E' solo un caso di omonimia.
Pag. 13 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Location:
shared repository: //10.10.7.249/Repository/sviluppi
Creazione di un branch centrale e suo popolamento (init, push, pull, checkout,
bind, unbind)
Esistono due diversi modi per
concettualmente ai seguenti casi.
fare
questa
operazione,
e
corrispondono
•
Esiste il nucleo di un progetto ed è sotto controllo di versione in un singolo
sistema locale. Lo vogliamo portare su un sistema centrale per poi poterlo
gestire con più addetti. In questo caso si crea un branch centrale vuoto
(comando init ), poi si copia il branch locale su quello centrale (comando
push ).
•
Il nucleo di un progetto non è sotto controllo di versione. Lo vogliamo
portare sotto controllo di versione su un sistema centrale. In questo caso si
crea un branch centrale vuoto (comando init ). Poi si crea un checkout
locale vuoto del branch predetto 5 . Si copiano i sorgenti nel checkout locale
e si fa commit localmente. La revisione appena creata viene copiata anche
sul repository centrale.
Si usano i comandi:
•
init , crea branch vuoto (già visto in Inizializzazione (init-repo, init) a
pag.5);
•
push , allinea il contenuto di un mirror (di solito centrale) del branch
corrente (di solito locale); i due branch non sono collegati da checkut;
•
pull , fa in modo che il branch corrente (di solito locale) divenga il mirror
di un altro branch (di solito centrale); i due branch non sono collegati da
checkout;
•
chechout , crea un working tree locale da un repository centrale (introdotto
in Inizializzazione, operazioni avanzate (branch, checkout, merge, resolve) a
pag.9); i due branch sono collegati: una commit sul locale produce la
revisione anche sul centrale;
•
bind , converte il branch corrente nel checkout di un altro branch;
•
unbind , converte il checkout corrente in un branch autonomo.
Esempio: caricamento di sorgenti su repository centrale da branch locale
Nel repository dell'esempio (2) (pag.13) vogliamo portare il progetto già sotto
controllo di versione dell'esempio (4) (a pag.7) e successivi.
Già che ci siamo, prima di usare il comando corretto ( push ), proviamo quello
sbagliato ( checkout : non va bene per legare un branch già esistente).
>bzr init file://10.10.7.249/Repository/sviluppi/sito
Created a repository branch (format: 2a)
5 Si ricordi che il checkout crea un branch locale legato al centrale. Una commit locale esegue la
copia della revisione anche sul centrale.
Pag. 14 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Using shared repository: //10.10.7.249/Repository/sviluppi/
>cd C:\...\sviluppo\repo
# errore: tentativo di checkout su branch già esistente!
>bzr checkout file://10.10.7.249/Repository/sviluppi/sito sito
bzr: ERROR: File exists: u'C:/.../sviluppo/repo/sito/.bzr': [Error 183]
Impossibile creare un file, se il file esiste gi:
u'C:/.../sviluppo/repo/sito/.bzr'
>cd C:/.../sviluppi/repo/sito
# invece il push funziona
>bzr push file://10.10.7.249/Repository/sviluppi/sito
Pushed up to revision 4.
Siccome successivamente proveremo il caricamento di sorgenti non versionati,
provvediamo ad eliminare il repository centrale. Nei comandi seguenti questo è
accessibile da Y:\sviluppi :
>Y:
Y:\\
>cd sviluppi
Y:\sviluppi\
>rmdir /s /q .bzr
>rmdir /s /q sito
Attenzione: il branch locale ha memoria dell'operazione di push. L'eliminazione del
repository centrale può creare problemi di disallineamento nel branch locale?
Questa è una ipotesi da indagare. Modifichiamo index.html e proviamo una commit :
>cd C:\...\sviluppo\repo\sito\
# il branch ricorda il push!
>bzr info
Repository tree (format: 2a)
Location:
shared repository: C:/Documents and Settings/de
falco/Desktop/writer.bazaar.note/sviluppo/repo
repository branch: .
Related branches:
push branch: //10.10.7.249/Repository/sviluppi/sito
submit branch: C:/Documents and
Settings/luciano/Desktop/writer.bazaar.note/sviluppo/repo/test-css
# modifichiamo index.html
>bzr status
modified:
index.html
>bzr commit -m "modified index, deleted central repository"
Committing to: C:/.../sviluppo/repo/sito/
modified index.html
Committed revision 5.
Funziona lo stesso! Bene.
Esempio: caricamento di sorgenti non versionati su repository centrale
Vogliamo vedere un esempio di caricamento di un repository centrale a partire da
Pag. 15 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
una directory di sorgenti ancora non sottoposta a versioning.
Mettiamo i sorgenti in una directory pulita, senza controllo di versioning. Ad
esempio copiamoli in c:\...\sviluppi\sito dell'esempio (3) (pag.7). Inoltre
ricreiamo il repository centrale vuoto come in esempio (2) di pag.13.
Dopo di che ricordiamoci di:
•
creare un branch centrale vuoto;
•
creare un checkout locale vuoto del branch predetto
•
copiare i sorgenti nel checkout locale
•
fare commit localmente; la revisione appena creata viene copiata anche sul
repository centrale.
Ecco la sequenza dei comandi.
(8). . . .# creiamo il repository centrale vuoto
>bzr init-repo --no-trees file://10.10.7.249/Repository/sviluppi
Shared repository (format: 2a)
Location:
shared repository: //10.10.7.249/Repository/sviluppi
# creiamo il branch principale centrale vuoto
>bzr init file://10.10.7.249/Repository/sviluppi/sito
Created a repository branch (format: 2a)
Using shared repository: //10.10.7.249/Repository/sviluppi/
# andiamo sul repository locale (ci deve essere. Se non c'è, crearlo)
>cd c:/.../sviluppi/repo
# facciamo checkout del centrale sul locale
>bzr checkout file://10.10.7.249/Repository/sviluppi/sito sito-checkout
# carichiamo e registriamo i file sul checkout locale
>cd sito-checkout
>copy ..\..\sito\*
..\..\sito\index.html
..\..\sito\page_1.html
..\..\sito\page_2.html
..\..\sito\test.css
4 file copiati.
>bzr add
adding index.html
adding page_1.html
adding page_2.html
adding test.css
# facciamo commit sul locale, si noti che lavora anche sul centrale
>bzr commit -m "caricam.iniziale del checkout, vale anche per rep. centrale"
Committing to: //10.10.7.249/Repository/sviluppi/sito/
added index.html
added page_1.html
added page_2.html
added test.css
Committed revision 1.
Lavorare con i checkout (update, commit, commit --local, bind, unbind)
Creare un repository centrale e caricarvi i sorgenti è solo l'inizio.
Pag. 16 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Ora si tratterà di usare il repository centrale da parte di più utenti. Come? Ogni
utente si crea localmente un checkout del main branch centrale. Dopo di che
lavora localmente, e quando ritiene opportuno fa commit. Ma la commit aggiorna il
repository centrale. Che avviene se qualcun altro ha fatto commit prima di lui? La
commit fallisce. Questo è il concetto base del lavoro in lockstep: non è permessa
una commit se i sorgenti locali non sono allineati al repository centrale.
I comandi fondamentali sono:
•
update , aggiorna il working tree locale rispetto il branch di riferimento;
•
commit , per creare una revisione sia nel branch locale che nel repository
centrale;
•
commit --local , invece effettua il commit del solo working tree locale
senza necessità del preventivo update e senza copiare la nuova revisione
sul branch di riferimento;
•
bind , unbind , sono usate per trasformare un branch in chechout e
viceversa, come pure per spostare un checkout da un main branch ad un
altro.
Si noti che l' update lavora con la stessa logica del merge . Di conseguenza si
capisce che possono sorgere conflitti durante questa operazione, conflitti da
risolvere per poi poter effettuare con successo una richiesta di commit .
Riguardo il comando commit con l'opzione -–local , Viene utilizzato per poter
lavorare con un checkout quando si è offline rispetto il repository centrale.
Quando si ritiene necessario effettuare nuovamente commit verso il repository
centrale, sarà necessario effettuare un update e poi il solito commit , questa volta
senza --local .
Esempio: modifiche a due checkout del main branch centrale
Riprendiamo la situazione finale dell'esempio (8) (pag.16).
Per
vedere
che
succede
lavorando
in
lockstep,
creiamo
dal
file://10.10.7.249/Repository/sviluppi/sito
i
due
working tree
c:\...\sviluppi\repo\sito-c1 e c:\...\sviluppi\repo\sito-c2
>cd C:\...\sviluppo\repo
centrale
locali:
>bzr checkout file://10.10.7.249/Repository/sviluppi/sito sito-c1
>bzr checkout file://10.10.7.249/Repository/sviluppi/sito sito-c2
Modifichiamo index.html in sito-c1 , facciamo commit , modifichiamo page_1.html
di s ito-c2 e facciamo commit : andiamo in errore perché sito-c2 non è allineato al
repository centrale.
>cd sito-c1
# modifichiamo index.html e facciamo commit
>bzr status
modified:
index.html
>bzr commit -m "sito-c1 modificato index.html"
Committing to: //10.10.7.249/Repository/sviluppi/sito/
Pag. 17 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
modified index.html
Committed revision 2.
# andiamo in sito-c2, modifica di page_01.html, commit: errore!
>cd ..\sito-c2
>bzr status
modified:
page_1.html
>bzr commit -m "sito-c2 modificato index.html"
bzr: ERROR: Bound branch BzrBranch7('file:///C:/.../sviluppo/repo/sito-c2/') is
out of date with master branch
BzrBranch7('file://10.10.7.249/Repository/sviluppi/sito/').
To commit to master branch, run update and then commit.
You can also pass --local to commit to continue working disconnected.
Come suggerito nel messaggio di errore: facciamo update e poi commit di nuovo.
>bzr update
M index.html
All changes applied successfully.
Updated to revision 2 of branch //10.10.7.249/Repository/sviluppi/sito
>bzr status
modified:
page_1.html
>bzr commit -m "sito-c2 modificato index.html"
Committing to: //10.10.7.249/Repository/sviluppi/sito/
modified page_1.html
Committed revision 3.
Ora la commit ha funzionato. Si nota che l' update non ha toccato il file page_1.html
che abbiamo modificato: funziona come il merge .
Esempio: commit locale e successivo riallineamento al branch centrale
Con il seguente scenario:
•
repository centrale su directory \\Pc-marco-home\landisk\sviluppi\
•
branch centrale su \\Pc-marco-home\landisk\sviluppi\sito
•
branch locale (copia di ...\sviluppi\repo\sito ) su ... \sviluppi\repo\home
Vogliamo trasformare il branch home in un checkout del branch centrale. Quindi
fare un paio di commit locali nel checkout. Infine riportare gli aggiornamenti sul
repository centrale.
# questo è un branch locale da cui carichiamo il repository centrale
>cd c:\...\sviluppi\repo\home
>bzr push \\Pc-marco-home\landisk\sviluppi\sito
Pushed up to revision 5.
# ora trasformiamo il branch in un checkout, la info conferma
>bzr bind \\Pc-marco-home\landisk\sviluppi\sito
>bzr info
Repository checkout (format: 2a)
Location:
repository checkout root: .
checkout of branch: //Pc-marco-home/landisk/sviluppi/sito
shared repository: C:/.../sviluppo/repo
Related branches:
Pag. 18 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
push branch: //Pc-marco-home/landisk/sviluppi/sito
parent branch: C:/.../sviluppo/repo/sito
# modifichiamo index.html e facciamo commit con il repository centrale
>bzr commit -m "index modified in home"
Committing to: //Pc-marco-home/landisk/sviluppi/sito/
modified index.html
Committed revision 6.
# modifichiamo altre due volte index.html e facciamo altrettanti commit locali
>bzr commit --local -m "index modified again in home"
Committing to: C:/Documents and
Settings/luciano/Desktop/writer.bazaar.note/sviluppo/repo/home/
modified index.html
Committed revision 7.
>bzr commit --local -m "index modified again and again in home"
Committing to: C:/.../sviluppo/repo/home/
modified index.html
Committed revision 8.
# nuova commit normale: ERRORE, perché non abbiamo fatto update
>bzr commit -m "now commiting to central repository"
bzr: ERROR: Bound branch BzrBranch7('file:///C:/.../sviluppo/repo/home/') is out
of date with master branch BzrBranch7('file://Pc-marcohome/landisk/sviluppi/sito/').
To commit to master branch, run update and then commit.
You can also pass --local to commit to continue working disconnected.
# procedura corretta: update (torniamo alla rev.6 del rep.centrale), poi commit
>bzr update
M index.html
All changes applied successfully.
M index.html
All changes applied successfully.
Updated to revision 6 of branch //Pc-marco-home/landisk/sviluppi/sito
Your local commits will now show as pending merges with 'bzr status', and can be
committed with 'bzr commit'.
>bzr commit -m "now commiting to central repository"
Committing to: //Pc-marco-home/landisk/sviluppi/sito/
modified index.html
Committed revision 7.
# il log ci mostra che siamo a rev.7
>bzr log
-----------------------------------------------------------revno: 7 [merge]
committer: ldfa <[email protected]>
branch nick: sito
timestamp: Fri 2010-05-07 22:25:52 +0200
message:
now commiting to central repository
#... CUTTED...
-----------------------------------------------------------revno: 1
committer: ldfa <[email protected]>
branch nick: sito
timestamp: Tue 2010-05-04 19:39:59 +0200
message:
primo snapshot
-----------------------------------------------------------Use --include-merges or -n0 to see merged revisions.
Cenni per lavorare in modalità distribuita
Per lavorare in modalità distribuita rispetto un repository centrale, si introduce un
Pag. 19 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
ulteriore livello di disaccoppiamento.
In pratica, ogni programmatore avrà il suo branch o checkout locale del repository
centrale. Ma questo non viene utilizzato direttamente per le modifiche al codice.
Piuttosto è una copia di riferimento del branch centrale, detta mirror branch. .
Dopo di che, ogni nuova funzione, o fix, viene sviluppata in un proprio branch,
detto feature branch 6 , creato a partire dal mirror branch .
Fin qui tutto come al solito. Ora vediamo come far confluire nel branch centrale
una funzione o una fix sviluppata in modo delocalizzato.
Sono possibili più scenari:
•
il più semplice prevede che ogni programmatore abbia i permessi per
aggiornare il branch centrale;
•
oppure possiamo avere un amministratore del repository centrale, cui è
delegata la responsabilità di controllare e accettare o meno lo sviluppo
proposto.
Inserimento di una nuova funzione nel trunk senza amministratore
Quando una funzione è pronta per confluire nel branch centrale, supponendo di
avere i permessi per aggiornare direttamente il branch centrale, si opera in tre
fasi:
•
si aggiorna il mirror branch (update se è un checkout, pull se è un brach)
rispetto il branch centrale;
•
si effettua il merge del mirror brench
risolvendo eventuali conflitti;
dal
•
si crea la revisione nel mirror
commit+push se è un branch).
(commit
branch
task branch
se
è
interessato,
un
checkout,
Inserimento di una nuova funzione nel trunk con amministratore
Se non si hanno i permessi di aggiornare il branch centrale, sarà necessario
inviare il codice da inserire all'amministratore del repository centrale.
Questa persona effettuerà l'analisi del codice con gli strumenti usuali (staus,
diff, ...). Se a valle di questa analisi, deciderà di accettare il codice ricevuto,
provvederà ad effettuare la commit .
Il comando di richiesta è:
•
send , invia 7 le informazioni 8 necessarie per richiedere una commit.
6 O task branch.
7 Invia tramite email, oppure è possibile avere in uscita un file, da controllare e successivamente
inviare autonomamente.
8 Si tratta di una sorta di mini-branch.
Pag. 20 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Appendici
Gestione del “warning some compiled extensions could not be loaded”
Nella mia configurazione a volte ho il warning:
bzr: warning: some compiled extensions could not be loaded; see ...(CUTTED)...
Per evitarlo, inserire la direttiva:
ignore_missing_extensions = True
nel file di configurazione bazaar.conf , che è nella directory:
C:\Documents and Settings\utente\Dati applicazioni\bazaar\2.0\
Nota. Questo problema non è stato risolto dall'installazione della libreria pywin32.
Utenza e password per il “file schema” in Windows non funzionano
Per effettuare operazioni verso server remoti spesso è necessario dichiarare
utenza e password. Ma in Windows per collegarsi a file system remoti Bazaar ha
problemi nell'utilizzare l'utenza necessaria.
A questo fine Bazaar prevede diverse possibilità. Ne ho provate due, entrambe con
esito negativo.
La prima è il file di configurazione authentication.conf , che è nella solita
directory: C:\Documents and Settings\ utente \Dati applicazioni\bazaar\2.0\
Il file viene letto, ma i valori inseriti non funzionano.
La seconda possibilità consiste nell'inserire utenza e password a linea di comando.
Ad esempio come segue:
bzr init-repo file://user:[email protected]/Repository/sviluppi/test-bazaar
anche in questo caso senza esito positivo.
Per questi motivi è necessario provvedere preventivamente, da sistema operativo,
ad instaurare un collegamento verso il server con le autenticazioni corrette. Ad
esempio si può usare:
net use Y: \\10.10.7.249\Repository password /USER:user
oppure effettuare un collegamento tramite Esplora risorse sulle risorse di rete.
Riferimenti
Id
[1]
[2]
[3]
[4]
Riferimento
Bazaar web home
Bazaar download
Bazaar documentation
Bazaar Tutorial
[5]
Bazaar User Guide
Autore
Nota
home del sito WEB di Bazaar
link per il download di Bazaar
Indice della documentazione di Bazaar
Bazaar Developers Introduzione all'utilizzo di Bazaar. Filename:
bzr-en-tutorial.pdf
Bazaar Developers Manuale d'uso di Bazaar. Filename:
bzr-en-user-guide.pdf
Pag. 21 of 22
Appunti per l'uso di Bazaar
cons. pubblica v.1.1 del 10 mag 2010
Acronimi e abbreviazioni
Acronimo
CVS
Nota
Concurrent Version System. E' l'antesignano dei programmi di controllo
versione. Il primo rilascio, autore Dick Grune, risale al 1986.
Continuamente migliorato dalla comunità open source.
Software Configuration Management. Un sinonimo di Version Control
System.
Apache Subversion. Inizialmente sviluppato nel 2000 da CollabNet Inc. E'
un altro programma di riferimento per il controllo versione.
Version Control System. Genericamente un sistema di controllo versione.
SCM
SVN
VCS
Identificazione e storia del documento
Ver
1.0
1.1
del
07 mag 2010
10 mag 2010
autore
Ldfa
Ldfa
Descrizione
Stesura iniziale
aggiunto commit --local
aggiunti i cenni per lavorare in modalità distribuita
Pag. 22 of 22