Capitolo 10. Gestione dei dati

Ecco una tabella riassuntiva degli strumenti di archiviazione e compressione disponibili per il sistema Debian.

Ecco una tabella riassuntiva dei semplici strumenti di copia e backup disponibili in un sistema Debian.

La copia dei file con rsync(8) offre un insieme di funzionalità più ricco di altri strumenti.

	Suggerimento
	L'esecuzione, tramite cron(8), dello script bkup citato in Sezione 10.2.3, «Uno script di copia per backup di dati» con l'opzione "-gl", dovrebbe fornire funzionalità moltio simili a dumpfs di Plan9 per un archivio di dati statici.

	Suggerimento
	Gli strumenti di controllo delle versioni VCS (Version control system) in Tabella 10.11, «Elenco di strumenti per sistemi di controllo delle versioni» possono essere usati come strumenti di copia e sincronizzazione multidirezionali.

Ecco diversi modi di archiviare ed estrarre archivi con l'intero contenuto della directory "./sorgente", usando diversi strumenti.

GNU tar(1):

$ tar -cvJf archivo.tar.xz ./sorgente
$ tar -xvJf archivo.tar.xz

In alternativa usare i comandi seguenti.

$ find ./sorgente -xdev -print0 | tar -cvJf archivo.tar.xz --null -F -

cpio(1):

$ find ./sorgente -xdev -print0 | cpio -ov --null > archivo.cpio; xz archivo.cpio
$ zcat archivo.cpio.xz | cpio -i

Ecco diversi modi di copiare l'intero contenuto della directory "./sorgente", usando diversi strumenti.

rsync(8):

# cd ./sorgente; rsync -aHAXSv . /dest
# cd ./sorgente; rsync -aHAXSv . utente@host.dom:/dest

In alternativa si può usare la sintassi con "una barra / alla fine della directory sorgente".

# rsync -aHAXSv ./sorgente/ /dest
# rsync -aHAXSv ./sorgente/ utente@host.dom:/dest

In alternativa usare i comandi seguenti.

# cd ./sorgente; find . -print0 | rsync -aHAXSv0 --files-from=- . /dest
# cd ./sorgente; find . -print0 | rsync -aHAXSv0 --files-from=- . utente@host.dom:/dest

GNU cp(1) e openSSH scp(1):

# cd ./sorgente; cp -a . /dest
# cd ./sorgente; scp -pr . utente@host.dom:/dest

GNU tar(1):

# (cd ./sorgente && tar cf - . ) | (cd /dest && tar xvfp - )
# (cd ./sorgente && tar cf - . ) | ssh utente@host.dom '(cd /dest && tar xvfp - )'

cpio(1):

# cd ./sorgente; find . -print0 | cpio -pvdm --null --sparse /dest

In tutti gli esempi contenenti ".", si può sostituire "." con "pippo" per copiare i file dalla directory "./sorgente/pippo" alla directory "/dest/pippo".

In tutti gli esempi contenenti ".", si può sostituire "." con il percorso assoluto "/percorso/di/sorgente/pippo" per evitare di fare "cd ./sorgente;". I file verranno copiati in posizioni diverse a seconda dello strumento utilizzato, come descritto qui di seguito.

	Suggerimento
	rsync(8) e GNU cp(1) hanno l'opzione "-u" per saltare i file che sono più recenti nella destinazione.

Un support di archiviazione removibile può essere uno dei seguenti.

	Suggerimento
	Vedere Sezione 9.8.1, «Cifratura di dischi removibili con dm-crypt/LUKS» per la condivisione interpiattaforma di dati usando cifratura a livello di dispositivo.

Il file system FAT è supportato da quasi tutti i sistemi operativi moderni ed è piuttosto utile per scopi di scambio di dati attraverso supporti come dischi fissi removibili.

Quando si formatta un dispositivo come un disco fisso removibile con il file system FAT per la condivisione interpiattaforma di dati, le scelte seguenti dovrebbero essere quelle più sicure.

Quando si condividono dati con un altro sistema attraverso una rete, si dovrebbero tenere a mente i servizi comuni. Ecco alcuni suggerimenti.

Sebbene questi file system montati in rete e metodi di trasferimento di file attraverso la rete siano piuttosto comodi per la condivisione dei dati, possono essere non sicuri. La loro connessione di rete deve essere resa sicura nel modo seguente.

Quello che segue è un elenco di importanti suite di utilità di backup disponibili in un sistema Debian

Gli strumenti di backup hanno una propria specializzazione.

Per un sistema desktop Debian personale con la suite unstable, devo proteggere solo i dati personali e quelli critici; tanto reinstallo comunque il sistema una volta all'anno. Perciò non ho ragione di fare il backup dell'intero sistema o di installare un'utilità completa di backup.

Uso un semplice script per fare un archivio di backup e masterizzarlo su CD/DVD usando una GUI. Ecco uno script di esempio che fa proprio questo.

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
BUUID=1000; USER=osamu # UID and name of a user who accesses backup files
BUDIR="/var/backups"
XDIR0=".+/Mail|.+/Desktop"
XDIR1=".+/\.thumbnails|.+/\.?Trash|.+/\.?[cC]ache|.+/\.gvfs|.+/sessions"
XDIR2=".+/CVS|.+/\.git|.+/\.svn|.+/Downloads|.+/Archive|.+/Checkout|.+/tmp"
XSFX=".+\.iso|.+\.tgz|.+\.tar\.gz|.+\.tar\.bz2|.+\.cpio|.+\.tmp|.+\.swp|.+~"
SIZE="+99M"
DATE=$(date --utc +"%Y%m%d-%H%M")
[ -d "$BUDIR" ] || mkdir -p "BUDIR"
umask 077
dpkg --get-selections \* > /var/lib/dpkg/dpkg-selections.list
debconf-get-selections > /var/cache/debconf/debconf-selections

{
find /etc /usr/local /opt /var/lib/dpkg/dpkg-selections.list \
     /var/cache/debconf/debconf-selections -xdev -print0
find /home/$USER /root -xdev -regextype posix-extended \
  -type d -regex "$XDIR0|$XDIR1" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
find /home/$USER/Mail/Inbox /home/$USER/Mail/Outbox -print0
find /home/$USER/Desktop  -xdev -regextype posix-extended \
  -type d -regex "$XDIR2" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
} | cpio -ov --null -O $BUDIR/BU$DATE.cpio
chown $BUUID $BUDIR/BU$DATE.cpio
touch $BUDIR/backup.stamp

Questo è pensato come esempio di script che deve essere eseguito da root.

Modificarlo ed eseguirlo nel modo seguente.

Per l'insieme dei dati in un albero di directory, la copia con "cp -a" fornisce normali backup.

Per un grande insieme di dati statici non sovrascritti in un albero di directory, come quello nella directory "/var/cache/apt/packages/", i collegamenti fisici creati con "cp -al" forniscono un'alternativa ai normali backup con un uso efficiente dello spazio su disco.

Ecco uno script di copia, che ho chiamato bkup, per il backup di dati. Questo script copia tutti i file (non-VCS) contenuti nella directory attuale in una directory datata nella directory genitore o in un host remoto.

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
fdot(){ find . -type d \( -iname ".?*" -o -iname "CVS" \) -prune -o -print0;}
fall(){ find . -print0;}
mkdircd(){ mkdir -p "$1";chmod 700 "$1";cd "$1">/dev/null;}
FIND="fdot";OPT="-a";MODE="CPIOP";HOST="localhost";EXTP="$(hostname -f)"
BKUP="$(basename $(pwd)).bkup";TIME="$(date  +%Y%m%d-%H%M%S)";BU="$BKUP/$TIME"
while getopts gcCsStrlLaAxe:h:T f; do case $f in
g)  MODE="GNUCP";; # cp (GNU)
c)  MODE="CPIOP";; # cpio -p
C)  MODE="CPIOI";; # cpio -i
s)  MODE="CPIOSSH";; # cpio/ssh
t)  MODE="TARSSH";; # tar/ssh
r)  MODE="RSYNCSSH";; # rsync/ssh
l)  OPT="-alv";; # hardlink (GNU cp)
L)  OPT="-av";;  # copy (GNU cp)
a)  FIND="fall";; # find all
A)  FIND="fdot";; # find non CVS/ .???/
x)  set -x;; # trace
e)  EXTP="${OPTARG}";; # hostname -f
h)  HOST="${OPTARG}";; # user@remotehost.example.com
T)  MODE="TEST";; # test find mode
\?) echo "use -x for trace."
esac; done
shift $(expr $OPTIND - 1)
if [ $# -gt 0 ]; then
  for x in $@; do cp $OPT $x $x.$TIME; done
elif [ $MODE = GNUCP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU";cp $OPT . "../$BU/"
elif [ $MODE = CPIOP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU"
  $FIND|cpio --null --sparse -pvd ../$BU
elif [ $MODE = CPIOI ]; then
  $FIND|cpio -ov --null | ( mkdircd "../$BU"&&cpio -i )
elif [ $MODE = CPIOSSH ]; then
  $FIND|cpio -ov --null|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&&cpio -i )"
elif [ $MODE = TARSSH ]; then
  (tar cvf - . )|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&& tar xvfp - )"
elif [ $MODE = RSYNCSSH ]; then
  rsync -aHAXSv ./ "${HOST}:${EXTP}-${BKUP}-${TIME}"
else
  echo "Any other idea to backup?"
  $FIND |xargs -0 -n 1 echo
fi

Questo script è pensato per essere un esempio per i comandi; leggerlo e modificarlo prima di usarlo.

	Suggerimento
	Io tengo questo script bkup nella mia directory "/usr/local/bin/" ed eseguo il comando bkup senza opzioni nella directory di lavoro ogni volta che ho bisogno di un backup istantaneo temporaneo.

	Suggerimento
	Per creare uno storico delle istantanee di un albero di file sorgenti o di un albero di file di configurazione, l'uso di git(7) è più semplice e più efficiente in termini di spazio (vedere Sezione 10.6.5, «Git per registrare la cronologia della configurazione»).

Quelli seguenti sono i significati dei codici di fiducia.

Il comando seguente carica la mia chiave "1DD8D791" sul popolare server di chiavi "hkp://keys.gnupg.net".

$ gpg --keyserver hkp://keys.gnupg.net --send-keys 1DD8D791

Un buon server di chiavi predefinito impostato in "~/.gnupg/gpg.conf" (o nella vecchia posizione "~/.gnupg/options") si ottiene la voce seguente.

keyserver hkp://keys.gnupg.net

Il comando seguente recupera le chiavi sconosciute dal server di chiavi.

$ gpg --list-sigs --with-colons | grep '^sig.*\[User ID not found\]' |\
  cut -d ':' -f 5| sort | uniq | xargs gpg --recv-keys

Aggiungere quanto seguie al file "~/.muttrc" per evitare che il lento GnuPG venga avviato automaticamente, permettendo allo stesso tempo di richiamarlo digitando "S" nel menu della vista indice.

macro index S ":toggle pgp_verify_sig\n"
set pgp_verify_sig=no

Il plugin gnupg permette di eseguire GnuPG in modo trasparente per i file con estensione ".gpg", ".asc" e ".pgp".

# aptitude install vim-scripts vim-addon-manager
$ vim-addons install gnupg

Si possono estrarre le differenze tra due file sorgenti e creare file diff unificati "file.patch0" o "file.patch1", a seconda della posizione del file, con le procedure seguenti.

$ diff -u file.vecchio file.nuovo > file.patch0
$ diff -u vecchio/file nuovo/file > file.patch1

I file diff (chiamati anche file patch) sono usati per inviare aggiornamenti per un programma. Chi li riceve applica questo aggiornamento ad un altro file nel modo seguente.

$ patch -p0 file < file.patch0
$ patch -p1 file < file.patch1

Se si hanno tre versioni di un codice sorgente, è possibile effettuare una fusione a 3 vie in maniera efficace usando diff3(1) nel modo seguente.

$ diff3 -m file.mio file.vecchio file.tuo > file

Quella che segue è una comparazione ipersemplificata, per dare un'idea generale dei comandi VCS nativi. La sequenza di comandi usata tipicamente può richiedere opzioni ed argomenti.

È possibile che si desideri impostare diverse configurazioni globali, come il nome e l'indirizzo di posta elettronica usati da Git, in "~/.gitconfig" nel modo seguente.

$ git config --global user.name "Nome Cognome"
$ git config --global user.email proprionome@esempio.com

Se si è abituati ai comandi di CVS o Subversion, si potrebbe volere impostare alcuni alias per i comandi nel modo seguente.

$ git config --global alias.ci "commit -a"
$ git config --global alias.co checkout

La configurazione globale può essere controllata con il comando seguente.

$ git config --global --list

Vedere la documentazione seguente.

Anche se l'archivio a monte usa un diverso VCS, potrebbe essere una buona idea usare git(1) per l'attività locale, dato che si può gestire la propria copia locale dell'albero dei sorgenti senza una connessione di rete con l'archivio a monte. Ecco alcuni pacchetti e comandi usati con git(1).

Si può fare il check out di un repository Subversion su "svn+ssh://svn.example.org/project/module/trunk" in un repository Git locale in "./dest" fare poi nuovamente il commit sul repository Subversion. Ad esempio:

$ git svn clone -s -rHEAD svn+ssh://svn.esempio.org/progetto dest
$ cd dest
... fare i cambiamenti
$ git commit -a
... continuare a lavorare localmente con git
$ git svn dcommit

	Suggerimento
	L'uso di "-rHEAD" permette di evitare di dover clonare tutti i contenuti della cronologia del repository Subversion.

La configurazione seguente permette solo ai membri del gruppo "src" di fare commit nell'archivio CVS e solo ai membri del gruppo "staff" di amministrare il CVS, riducendo perciò le possibilità di autodanneggiarsi.

# cd /var/lib; umask 002; mkdir cvs
# export CVSROOT=/srv/cvs/progetto
# cd $CVSROOT
# chown root:src .
# chmod 2775 .
# cvs -d $CVSROOT init
# cd CVSROOT
# chown -R root:staff .
# chmod 2775 .
# touch val-tags
# chmod 664 history val-tags
# chown root:src history val-tags

	Suggerimento
	Si può limitare la creazione di nuovi progetti modificando il proprietario della directory "$CVSROOT" in "root:staff" e i suoi permessi in "3775".

L'archivio CVS predefinito è indicato da "$CVSROOT". Il comando seguente imposta "$CVSROOT" per l'accesso locale.

$ export CVSROOT=/srv/cvs/progetto

Creare un nuovo albero di sorgenti locale in "~/percorso/di/modulo1" con il comando seguente.

$ mkdir -p ~/percorso/di/modulo1; cd ~/percorso/di/modulo1

Popolare il nuovo albero di sorgenti locale in "~/percorso/di/modulo1" con i file.

Importarlo nel CVS con i parametri seguenti.

$ cd ~/percorso/di/modulo1
$ cvs import -m "Inizio di modulo1" Ramo-principale Rilascio-iniziale
$ rm -Rf . # opzionale

CVS non sovrascrive i file attuali nell'archivio, ma li sostituisce con altri. Perciò i permessi di scrittura della directory dell'archivio sono fondamentali. Per ogni nuovo modulo di modulo1" nell'archivio in "/srv/cvs/progetto", eseguire i comandi seguenti per assicurare che i permessi siano corretti, se necessario.

# cd /srv/cvs/progetto
# chown -R root:src modulo1
# chmod -R ug+rwX   modulo1
# chmod    2775     modulo1

Ecco un esempio di una sequenza tipica di azioni svolte nell'uso di CVS.

Controllare tutti i moduli disponibili dal progetto CVS a cui punta "$CVSROOT" con il comando seguente.

$ cvs rls
CVSROOT
modulo1
modulo2
...

Fare il checkout di "modulo1" nella sua directory predefinita "./modulo1" con il comando seguente.

$ cd ~/percorso/di
$ cvs co modulo1
$ cd modulo1

Fare i cambiamenti desiderati necessari ai contenuti.

Controllare i cambiamenti facendo l'equivalente di "diff -u [archivio] [locale]" con il comando seguente.

$ cvs diff -u

Si scopre, ad esempio, di aver corrotto gravemente un file "file_da_ripristinare", ma gli altri file sono a posto.

Sovrascrivere "file_da_ripristinare" con una copia pulita dal CVS con il comando seguente.

$ cvs up -C file_da_ripristinare

Salvare l'albero dei sorgenti locale aggiornato sul CVS con il comando seguente.

$ cvs ci -m "Descrivere qui i cambiamenti"

Creare ed aggiungere il file "file_da_aggiungere" al CVS con il comando seguente.

$ vi file_da_aggiungere
$ cvs add file_da_aggiungere
$ cvs ci -m "Aggiunto file_da_aggiungere"

Fondere la versione più recente dal CVS con il comando seguente.

$ cvs up -d

Prestare attenzione alle righe che iniziano con "C nomefile" che indicano le modifiche che creano conflitti.

Cercare il codice non modificato in ".#nomefile.versione".

Per trovare le modifiche che creano conflitti cercare "<<<<<<<" e ">>>>>>>" nei file.

Modificare i file in modo da risolvere i conflitti.

Aggiungere un'etichetta di rilascio "Rilascio-1" nel modo seguente.

$ cvs ci -m "ultimo commit per Rilascio-1"
$ cvs tag Rilascio-1

Modificare ulteriormente.

Rimuovere l'etichetta di rilascio "Rilascio-1" con il comando seguente.

$ cvs tag -d Rilascio-1

Fare il commit delle modifiche sul CVS con il comando seguente.

$ cvs ci -m "ultimissimo commit per Rilascio-1"

Riaggiungere l'etichetta di rilascio "Rilascio-1" all'HEAD CVS aggiornato principale con il comando seguente.

$ cvs tag Rilascio-1

Creare un ramo con un'etichetta permanente "Rilascio-iniziale-risoluzionebug" dalla versione originale a cui punta l'etichetta "Rilascio-iniziale" e farne il checkout nella directory "~/percorso/di/vecchio" nel modo seguente.

$ cvs rtag -b -r Rilascio-iniziale Rilascio-iniziale-risoluzionebug modulo1
$ cd ~/percorso/di
$ cvs co -r Rilascio-iniziale-risoluzionebug -d vecchio modulo1
$ cd vecchio

	Suggerimento
	Per specificare una particolare data come punto di ramificazione, usare "-D 2005-12-20" (formato ISO 8601 per le date) invece di "-r Rilascio-iniziale".

Lavorare in questo albero locale di sorgenti che ha l'etichetta permanente "Rilascio-iniziale-risoluzionebug" e che è basato sulla versione originale.

Lavorare in questo ramo da soli … fino a che qualcun altro non si aggiunge al ramo "Rilascio-iniziale-risoluzionebug".

Fare la sincronizzazione dei file modificati da altri in questo ramo, creando contemporaneamente nuove directory se necessario, con il comando seguente.

$ cvs up -d

Modificare i file in modo da risolvere i conflitti.

Fare il commit delle modifiche sul CVS con il comando seguente.

$ cvs ci -m "fatto il commit in questo ramo"

Aggiornare l'albero locale con l'HEAD del principale, rimuovendo allo stesso tempo l'etichetta permanente ("-A") e senza espansione delle parole chiave ("-kk"), con il comando seguente.

$ cvs up -d -kk -A

Aggiornare l'albero locale (contenuto = HEAD del principale) fondendo dal ramo "Rilascio-iniziale-risoluzionebug" e senza espansione delle parole chiave con il comando seguente.

$ cvs up -d -kk -j Rilascio-iniziale-risoluzionebug

Correggere i conflitti con l'editor.

Fare il commit delle modifiche sul CVS con il comando seguente.

$ cvs ci -m "fusione con Rilascio-iniziale-risoluzionebug"

Creare un file archivio nel modo seguente.

$ cd ..
$ mv vecchio vecchio-modulo1-risoluzionebug
$ tar -cvzf vecchio-modulo1-risoluzionebug.tar.gz vecchio-modulo1-risoluzionebug
$ rm -rf vecchio-modulo1-risoluzionebug

	Suggerimento
	Il comando "cvs up" accetta l'opzione "-d" per creare nuove directory e l'opzione "-P" per eliminare le directory vuote.

	Suggerimento
	Si può fare il checkout solamente di una sottodirectory di "modulo1" fornendo il suo nome come in "cvs co modulo1/sottodir".

Per ottenere i file più recenti dal CVS usare "tomorrow" nel modo seguente.

$ cvs ex -D tomorrow nome_modulo

Aggiungere l'alias "mx" per un modulo ad un progetto CVS (server locale) usando il comando seguente.

$ export CVSROOT=/srv/cvs/progetto
$ cvs co CVSROOT/moduli
$ cd CVSROOT
$ echo "mx -a modulo1" >>moduli
$ cvs ci -m "Ora mx e' un alias per modulo1"
$ cvs release -d .

Ora si può fare il checkout di "modulo1" (alias: "mx") dal CVS alla directory "nuova" nel modo seguente.

$ cvs co -d nuova mx
$ cd nuova

	Nota
	Per seguire la procedura precedente sono necessari gli adeguati permessi sui file.

Quando si fa il checkout di file dal CVS viene mantenuto il loro bit del permesso di esecuzione.

Ogni volta si incontrano problemi con i permessi di esecuzione di un file di cui si è fatto il checkout, ad esempio "nomefile", per risolverli cambiare i suoi permessi nell'archivio CVS corrispondente nel modo seguente.

# chmod ugo-x nomefile

Attualmente il pacchetto subversion non imposta un archivio, perciò è necessario farlo manualmente. Una possibile collocazione per un archivio è in "/srv/svn/progetto".

Creare una directory con il comando seguente

# mkdir -p        /srv/svn/progetto

Creare il database dell'archivio con il comando seguente.

# svnadmin create /srv/svn/progetto

Se si accede all'archivio Subversion solamente attraverso il server Apache2, è necessario soltanto rendere l'archivio scrivibile dal server WWW, nel modo seguente.

# chown -R www-data:www-data /srv/svn/progetto

Per permettere l'accesso all'archivio tramite autenticazione dell'utente aggiungere (o decommentare) quanto segue in "/etc/apache2/mods-available/dav_svn.conf".

<Location /progetto>
  DAV svn
  SVNPath /srv/svn/progetto
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
</LimitExcept>
</Location>

Creare un file di autenticazione dell'utente con il comando seguente.

# htpasswd2 -c /etc/subversion/passwd un-qualche-nomeutente

Riavviare Apache2.

Il nuovo archivio Subversion è accessibile da svn(1) agli URL "http://localhost/progetto" e "http://esempio.com/progetto" (assumendo che l'URL del proprio server web sia "http://esempio.com/").

I comandi seguenti impostano l'archivio Subversion per l'accesso locale da parte di un gruppo, ad esempio progetto.

# chmod  2775     /srv/svn/progetto
# chown -R root:src /srv/svn/progetto
# chmod -R ug+rwX   /srv/svn/progetto

Il nuovo archivio Subversion è accessibile con svn(1) per gli utenti locali che appartengono al gruppo progetto, all'URL "file:///localhost/srv/svn/progetto" o "file:///srv/svn/progetto". Per assicurare l'accesso al gruppo è necessario usare i programmi come svn, svnserve, svnlook e svnadmin con "umask 002".

Se esiste un archivio Subversion accessibile da un gruppo all'URL "esempio.com:/srv/svn/progetto", si può accedere ad esso con svn(1) e SSH all'URL "svn+ssh://esempio.com:/srv/svn/progetto".

Per compensare la mancanza di rami ed etichette in Subversion, molti progetti usano con esso un albero di directory simile al seguente.

  ----- modulo1
    |   |-- branches
    |   |-- tags
    |   |   |-- rilascio-1.0
    |   |   `-- rilascio-2.0
    |   |
    |   `-- trunk
    |       |-- file1
    |       |-- file2
    |       `-- file3
    |
    `-- modulo2

	Suggerimento
	Per marcare i rami e le etichette è necessario usare il comando "svn copy …". Ciò assicura che Subversion regisstri la cronologia dei cambiamenti dei file in maniera corretta e risparma spazio.

Creare un nuovo albero di sorgenti locale in "~/percorso/di/modulo1" con il comando seguente.

$ mkdir -p ~/percorso/di/modulo1; cd ~/percorso/di/modulo1

Popolare il nuovo albero di sorgenti locale in "~/percorso/di/modulo1" con i file.

Importarlo In Subversion con i parametri seguenti.

$ cd ~/percorso/di/modulo1
$ svn import file:///srv/svn/progetto/modulo1/trunk -m "Inizo di modulo1"
$ svn cp file:///srv/svn/progetto/modulo1/trunk file:///srv/svn/progetto/modulo1/tags/Rilascio-iniziale

In alternativa usare i comandi seguenti.

$ svn import ~/percorso/di/modulo1 file:///srv/svn/progetto/modulo1/trunk -m "Inizo di modulo1"
$ svn cp file:///srv/svn/progetto/modulo1/trunk file:///srv/svn/progetto/modulo1/tags/Rilascio-iniziale

	Suggerimento
	Si possono sostituire gli URL come "file:///…" con URL in qualsiasi altro formato, come "http://…" e "svn+ssh://…".

Ecco un esempio di una sequenza tipica di azioni svolte nell'uso di Subversion con il suo client nativo.

	Suggerimento
	I comandi client forniti dal pacchetto git-svn possono offrire un metodo alternativo di lavoro con Subversion con l'uso del comando git. Vedere Sezione 10.6.4, «Git per repository Subversion».

Controllare tutti i moduli disponibili dal progetto Subversion a cui punta l'URL "file:///srv/svn/progetto" con il comando seguente.

$ svn list file:///srv/svn/progetto
modulo1
modulo2
...

Fare il checkout di "modulo1/trunk" in una directory "./modulo1" con il comando seguente.

$ cd ~/percorso/di
$ svn co file:///srv/svn/progetto/modulo1/trunk modulo1
$ cd modulo1

Fare i cambiamenti desiderati necessari ai contenuti.

Controllare i cambiamenti facendo l'equivalente di "diff -u [archivio] [locale]" con il comando seguente.

$ svn diff

Si scopre, ad esempio, di aver corrotto gravemente un file "file_da_ripristinare", ma gli altri file sono a posto.

Sovrascrivere "file_da_ripristinare" con una copia pulita da Subversion con il comando seguente.

$ svn revert file_da_ripristinare

Salvare l'albero dei sorgenti locale aggiornato su Subversion con il comando seguente.

$ svn ci -m "Descrivere qui i cambiamenti"

Creare ed aggiungere il file "file_da_aggiungere" a Subversion con il comando seguente.

$ vi file_da_aggiungere
$ svn add file_da_aggiungere
$ svn ci -m "Aggiunto file_da_aggiungere"

Fondere la versione più recente da Subversion con il comando seguente.

$ svn up

Prestare attenzione alle righe che iniziano con "C nomefile" che indicano le modifiche che creano conflitti.

Cercare codice non modificato in, ad esempio "nomefile.r6", "nomefile.r9" e "nomefile.mio".

Per trovare le modifiche che creano conflitti cercare "<<<<<<<" e ">>>>>>>" nei file.

Modificare i file in modo da risolvere i conflitti.

Aggiungere un'etichetta di rilascio "Rilascio-1" nel modo seguente.

$ svn ci -m "ultimo commit per Rilascio-1"
$ svn cp file:///srv/svn/progetto/modulo1/trunk file:///srv/svn/progetto/modulo1/tags/Rilascio-1

Modificare ulteriormente.

Rimuovere l'etichetta di rilascio "Rilascio-1" con il comando seguente.

$ svn rm file:///srv/svn/progetto/modulo1/tags/Rilascio-1

Fare il commit delle modifiche su Subversion con il comando seguente.

$ svn ci -m "ultimissimo commit per Rilascio-1"

Riaggiungere l'etichetta di rilascio "Rilascio-1" all'HEAD CVS aggiornato di trunk con il comando seguente.

$ svn cp file:///srv/svn/progetto/modulo1/trunk file:///srv/svn/progetto/modulo1/tags/Rilascio-1

Creare un ramo con percorso "modulo1/branches/Rilascio-iniziale-risoluzionebug" dalla versione originale a cui punta il percorso "modulo1/tags/Rilascio-iniziale" e farne il checkout nella directory "~/percorso/di/vecchio" nel modo seguente.

$ svn cp file:///srv/svn/progetto/modulo1/tags/Rilascio-initzale file:///srv/svn/progetto/modulo1/branches/Rilascio-iniziale-risoluzionebug
$ cd ~/percorso/di
$ svn co file:///srv/svn/progetto/modulo1/branches/Rilascio-iniziale-risoluzionebug vecchio
$ cd vecchio

	Suggerimento
	Per specificare una particolare data come punto di ramificazione, usare "modulo1/trunk@{2005-12-20}" (formato ISO 8601 per le date) invece di "modulo1/tags/Rilascio-iniziale".

Lavorare in questo albero locale di sorgenti che punta al ramo "Rilascio-iniziale-risoluzionebug" e che è basato sulla versione originale.

Lavorare in questo ramo da soli … fino a che qualcun altro non si aggiunge al ramo "Rilascio-iniziale-risoluzionebug".

Fare la sincronizzazione con i file in questo ramo modificati da altri, con il comando seguente.

$ svn up

Modificare i file in modo da risolvere i conflitti.

Fare il commit delle modifiche su Subversion con il comando seguente.

$ svn ci -m "fatto il commit in questo ramo"

Aggiornare l'albero locae con HEAD di trunk nel modo seguente.

$ svn switch file:///srv/svn/progetto/modulo1/trunk

Aggiornare l'albero locale (contenuto = HEAD di trunk) fondendo dal ramo "Rilascio-iniziale-risoluzionebug" con il comando seguente.

$ svn merge file:///srv/svn/progetto/modulo1/branches/Rilascio-iniziale-risoluzionebug

Correggere i conflitti con l'editor.

Fare il commit delle modifiche su Subversion con il comando seguente.

$ svn ci -m "fusione con Rilascio-iniziale-risoluzionebug"

Creare un file archivio nel modo seguente.

$ cd ..
$ mv vecchio vecchio-modulo1-risoluzionebug
$ tar -cvzf vecchio-modulo1-risoluzionebug.tar.gz vecchio-modulo1-risoluzionebug
$ rm -rf vecchio-modulo1-risoluzionebug

	Suggerimento
	Si possono sostituire gli URL come "file:///…" con URL in qualsiasi altro formato, come "http://…" e "svn+ssh://…".

	Suggerimento
	Si può fare il checkout solamente di una sottodirectory di "modulo1" fornendo il suo nome come in "svn co file:///srv/svn/progetto/modulo1/trunk/sottodir modulo1/sottodir", ecc.