Chapitre 10. Gestion des données

Voici un résumé des outils d’archivage et de compression disponible sur le système Debian :

Voici une liste d’outils simples de copie et de sauvegarde sur le système Debian :

Copier des fichiers avec rsync(8) offres des fonctionnalités plus riches que les autres méthodes.

	Astuce
	L’exécution du script bkup mentionné dans Section 10.2.3, « Un script de copie pour la sauvegarde des données » avec l’option « -gl » sous cron(8) fournira une fonctionnalité très semblable à dumpfs de Plan9 pour l’archivage des données statiques.

	Astuce
	Les outils de système de contrôle de version (VCS) de Tableau 10.11, « Liste d’outils pour les systèmes de contrôle de version » peuvent fonctionner comme outils de synchronisation et de copie multi-voies.

Voici quelques manières d’archiver et de désarchiver le contenu entier du répertoire « ./source » en utilisant différents outils.

GNU tar(1) :

$ tar -cvJf archive.tar.xz ./source
$ tar -xvJf archive.tar.xz

ou encore, comme suit :

$ find ./source -xdev -print0 | tar -cvJf archive.tar.xz --null -F -

cpio(1) :

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

Voici quelques manières d’archiver et de désarchiver le contenu entier du répertoire « ./source » en utilisant différents outils.

rsync(8):

# cd ./source; rsync -aHAXSv . /dest
# cd ./source; rsync -aHAXSv . user@host.dom:/dest

Vous pouvez, en remplacement, utiliser la syntaxe « un slash en fin du répertoire source ».

# rsync -aHAXSv ./source/ /dest
# rsync -aHAXSv ./source/ user@host.dom:/dest

ou encore, comme suit :

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

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

# cd ./source; cp -a . /dest
# cd ./source; scp -pr . user@host.dom:/dest

GNU tar(1) :

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

cpio(1) :

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

Vous pouvez remplacer « . » par « truc » dans tous les exemples comportant « . » pour copier les fichiers du répertoire « ./source/truc » vers le répertoire « /dest/truc ».

Vous pouvez remplacer « . » par le chemin absolu « /chemin/vers/source/truc » dans tous les exemples comportant « . » pour éviter « cd ./source; ». Cela permet de copier les fichiers vers différents emplacements selon les outils utilisés de la manière suivante :

	Astuce
	rsync(8) et GNU cp(1) possèdent l’option « -u » pour sauter les fichiers qui sont plus récents sur la destination.

Les périphériques d’enregistrement amovibles possibles sont les suivants.

	Astuce
	Consultez Section 9.8.1, « Chiffrement des disques amovibles à l’aide de dm-crypt/LUKS » pour le partage de données entre plateformes en utilisant le chiffrement au niveau du périphérique.

Le système de fichiers FAT est pris en charge par la plupart des systèmes d’exploitation modernes et est assez utile pour l'échange des données par l’intermédiaire de supports du type disque dur amovible.

Pour le formatage de périphériques de type disque dur amovible pour l’échange de données entre plateformes avec un système de fichiers FAT, ce qui suit peut être un choix sûr :

Lors du partage de données avec d’autres systèmes au travers du réseau, vous devrez utiliser un service commun. Voici quelques éléments :

Bien que ces systèmes de fichiers montés au travers du réseau et les méthodes de transfert au travers du réseau soient assez pratiques pour partager des données, elles peuvent être non sûres. Leur connexion réseau doit être sécurisée par ce qui suit :

Voici une liste d’utilitaires de sauvegarde notables disponibles sur le système Debian :

Les outils de sauvegarde ont chacun des objectifs particuliers.

Pour un système de bureau personnel Debian sur lequel tourne la version unstable, je n’ai besoin de protéger que les données personnelles et les données critiques. Je réinstalle cependant le système une fois par an. Je ne vois donc aucune raison de sauvegarder l’ensemble du système ou d’installer un utilitaire de sauvegarde ayant des fonctionnalités avancées.

J’utilise un simple script pour réaliser des archives de sauvegarde et les graver sur CD/DVD en utilisant une interface graphique. Voici un exemple de script pour ce faire :

#!/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

C’est destiné à être un script d’exemple exécuté avec le compte de l’administrateur.

Vous devrez le modifier et l’exécuter comme suit :

Pour les données se trouvant sous l’arborescence d’un répertoire, une copie avec « cp -a » permet une sauvegarde normale.

Pour un gros ensemble de données statiques ne devant pas être réécrites se trouvant dans une arborescence de répertoires telle que celle se trouvant sous le répertoire « /var/cache/apt/packages/ », les liens physiques avec « cp -al » fournissent une alternative à la sauvegarde normale avec une utilisation efficace de l’espace disque.

Voici un script de copie, que j’ai appelé bkup, destiné à la sauvegarde de données. Ce script copie tous les fichiers (non-VCS) du répertoire actuel vers le répertoire daté du répertoire parent ou sur une machine distante.

#!/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";; # lien physique (GNU cp)
L)  OPT="-av";;  # copier (GNU cp)
a)  FIND="fall";; # tout rechercher
A)  FIND="fdot";; # rechercher ce qui n'est pas CVS/ .???/
x)  set -x;; # trace
e)  EXTP="${OPTARG}";; # hostname -f
h)  HOST="${OPTARG}";; # utilisateur@remotehost.example.com
T)  MODE="TEST";; # tester le mode de recherche
\?) echo "utiliser -x pour une 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 "Une autre idée à sauvegarder ?"
  $FIND |xargs -0 -n 1 echo
fi

C’est destiné à être un exemple de commandes. Veuillez lire le script et le modifier vous-même avant de l’utiliser.

	Astuce
	J’ai installé ce bkup dans mon répertoire « /usr/local/bin/ ». J’utilise cette commande bkup, sans aucune option, depuis mon répertoire de travail lorsque j’ai besoin d’un instantané temporaire de sauvegarde.

	Astuce
	Pour faire un instantané historique d’une arborescence de fichiers sources ou d’une arborescence de fichiers de configuration, il est plus facile et efficace d’utiliser git(7) (consultez Section 10.6.5, « Git pour l’enregistrement de l’historique de la configuration »).

Voici la signification du code de confiance

Ce qui suit permet d’envoyer ma clé « 1DD8D791 » vers le serveur de clé populaire « hkp://keys.gnupg.net » :

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

Une bonne configuration de serveur de clés dans « ~/.gnupg/gpg.conf » (ou à l’ancien emplacement « ~/.gnupg/options ») contient ce qui suit :

keyserver hkp://keys.gnupg.net

Ce qui suit obtient les clés inconnues du serveur de clés :

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

Ajoutez ce qui suit à « ~/.muttrc » afin d’éviter que GnuPG qui est lent ne démarre automatiquement, tout en permettant son utilisation en entrant « S » depuis l’index du menu :

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

Le greffon gnupg vous permet de lancer GnuPG de manière transparente pour les fichiers ayant l’extension « .gpg », « .asc » et « .ppg ».

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

Suivez une des procédures suivantes pour extraire les différences entre deux fichiers sources et créer un fichier de différences unifié « fichier.patch0 » ou « fichier.patch1 » selon l’emplacement du fichier.

$ diff -u fichier.ancien fichier.nouveau > fichier.patch0
$ diff -u ancien/fichier nouveau/fichier > fichier.patch1

Le fichier de différences (« diff » (encore appelé fichier « patch » ou rustine) est utilisé pour envoyer une mise à jour de programme. Celui qui reçoit applique cette mise à jour à un autre fichier de la manière suivante :

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

Si vous avez trois versions d’un code source, vous pouvez effectuer de manière efficace une fusion des trois en utilisant diff3(1) de la manière suivante :

$ diff3 -m fichier.mien fichier.ancien fichier.votre > fichier

Voici une comparaison très simplifiée des commandes natives de VCS destinées à donner une vue d’ensemble. La séquence de commandes typique peut demander des options et des paramètres.

Vous pourrez définir certains éléments de configuration globaux, comme votre nom et votre adresse de courriel utilisée par Git, dans « ~/.gitconfig » de la manière suivante :

$ git config --global nom.utilisateur "Prénom Nom"
$ git config --global nom-utilisateur.email votre-nom@example.com

Si vous avez l’habitude d’utiliser les commandes de CVS ou de Subversion, vous pourrez définir certains alias de commandes comme suit :

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

Vous pouvez vérifier votre configuration globale de la manière suivante :

$ git config --global --list

Consultez ce qui suit :

Même si votre source amont utilise un VCS différent, c’est une bonne idée d’utiliser git(1) pour l’activité locale parce qu’il vous permet de gérer votre copie locale de l’arborescence des sources sans connexion réseau amont. Voici quelques paquets et commandes utilisés avec git(1).

Un dépôt Subversion en « svn+ssh://svn.example.org/project/module/trunk » peut être extrait vers un dépôt Git local en « ./dest » puis renvoyé vers le dépôt subversion. Par exemple :

$ git svn clone -s -rHEAD svn+ssh://svn.example.org/project dest
$ cd dest
... effectuer des modifications
$ git commit -a
... travailler encore avec git
$ git svn dcommit

	Astuce
	L’utilisation de « rHEAD » nous permet d’éviter de devoir cloner l’ensemble du contenu de l’historique du dépôt Subversion.

La configuration suivante permet de ne faire des dépôts (« commit ») vers le dépôt du CVS que par les membres du groupe « src » et l’administration du CVS que par un membre du groupe « staff », réduisant ainsi la chance de se détruire soi-même.

# cd /var/lib; umask 002; mkdir cvs
# export CVSROOT=/srv/cvs/projet
# 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

	Astuce
	Vous pouvez restreindre la création d’un nouveau projet en modifiant le propriétaire du répertoire « $CVSROOT » pour « root:staff » et ses permissions à « 3775 ».

La variable « $CVSROOT » pointe vers le dépôt par défaut. Ce qui suit définit « $CVSROOT » pour l’accès local :

$ export CVSROOT=/srv/cvs/project

Créez un nouvel emplacement d’arborescence locale des sources dans « ~/chemin/vers/module1 » par la commande suivante :

$ mkdir -p ~/chemin/vers/module1; cd ~/chemin/vers/module1

Mettez des fichiers dans la nouvelles arborescence locale de sources se trouvant en « ~/chemin/vers/module1 ».

Importez-les vers CVS avec les paramètres suivants :

$ cd ~/chemin/vers/module1
$ cvs import -m "Start module1" module1 Branche-principale Version-initiale
$ rm -Rf . # optionnel

CVS n’écrase pas un fichier du dépôt actuel mais le remplace par un autre. La permission en écriture vers le répertoire du dépôt est donc critique. Lancez ce qui suit, pour chaque nouveau module de « module1 » dans le dépôt à « /srv/cvs/projet », afin de vous assurer, si nécessaire, que cette condition est remplie :

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

Voici un exemple de flux de travail typique utilisant CVS.

Vérifiez tous les modules disponibles du projet CVS pointé par « $CVSROOT » comme suit :

$ cvs rls
CVSROOT
module1
module2
...

Récupérez le « module1 » depuis son répertoire par défaut « ./module1 » de la manière suivante :

$ cd ~/path/to
$ cvs co module1
$ cd module1

Effectuez les modifications de contenu au besoin.

Vérifiez les modifications par un équivalent de « diff -u [repository] [local] » de la manière suivante :

$ cvs diff -u

Vous-vous apercevez que vous avez cassé sévèrement un fichier appelé « fichier_à_restaurer » mais que les autres fichiers sont corrects.

Écrasez le fichier « fichier_à_restaurer » avec une copie propre venant du CVS de la manière suivante :

$ cvs up -C fichier_à_restaurer

Enregistrez l’arborescence source locale vers le CVS comme suit :

$ cvs ci -m "Décrire les modifications"

Créez et ajoutez le fichier « fichier_à_ajouter » au CVS comme suit :

$ vi fichier_à_ajouter
$ cvs add fichier_à_ajouter
$ cvs ci -m "Ajout de fichier_à_ajouter"

Fusionnez la dernière version depuis le CVS comme suit :

$ cvs up -d

Recherchez les lignes commençant par « C filename » qui indiquent des modifications en conflit.

Recherchez du code non modifié dans « .#nom_fichier.version ».

Recherchez « <<<<<<< » et « >>>>>>> » dans les fichiers qui indiquent des conflits de modifications.

Au besoin, éditez les fichiers pour résoudre les conflits.

Ajoutez l’étiquette de version (« release tag« ») « Version-1 » comme suit :

$ cvs ci -m "dernière proposition pour Version-1"
$ cvs tag Version-1

Poursuivez l’édition.

Supprimez l’étiquette de version « Version-1  » comme suit :

$ cvs tag -d Version-1

Vérifiez les modifications du CVS comme suit :

$ cvs ci -m "vraiment la dernière proposition pour Version-1"

Ajoutez de nouveau, de la manière suivante, l’étiquette « Version-1 » à HEAD de « main » du CVS mis à jour :

$ cvs tag Version-1

Créez une branche avec une étiquette de branche « collante » Version-initiale-corrections-de-bogues » depuis la version d’origine pointée par l’étiquette « Version-initiale » et exportez-la vers le répertoire ~/chemin/vers/ancien » comme suit :

$ cvs rtag -b -r Version-initiale Version-initiale-corrections-de-bogues module1
$ cd ~/chemin/vers
$ cvs co -r Version-initiale-corrections-de-bogues -d ancien module1
$ cd ancien

	Astuce
	Utilisez  -D 2005-12-20 » (format de date ISO 8601) plutôt que « -r Version-initiale » pour indiquer une date particulière comme point de branche.

Travaillez sur cette arborescence locale possédant l’étiquette « collante » « Version-initiale-corrections-de-bogues » qui est basée sur la version d’origine.

Travaillez vous-même sur cette branche… jusqu’à ce que quelqu’un d’autre rejoigne cette branche « Version-initiale-corrections-de-bogues ».

Synchronisez les fichiers modifiés par d’autres sur cette branche, en créant de nouveaux répertoires si nécessaire, de la manière suivante :

$ cvs up -d

Au besoin, éditez les fichiers pour résoudre les conflits.

Vérifiez les modifications du CVS comme suit :

$ cvs ci -m "checked into this branch"

Mettez à jour l’arborescence locale depuis HEAD de main en supprimant l’étiquette collante (« sticky tag ») (« -A ») et sans expansion de mots-clés (« -kk ») comme suit :

$ cvs up -d -kk -A

Mettez à jour l’arborescence locale (contenu = HEAD de main) en fusionnant depuis la branche « Version-initiale-corrections-de-bogues » et sans expansion des mots-clés en faisant ce qui suit :

$ cvs up -d -kk -j Version-initiale-corrections-de-bogues

Corrigez les conflits avec l’éditeur.

Vérifiez les modifications du CVS comme suit :

$ cvs ci -m "Version-initiale-corrections-de-bogues fusionnée"

Réalisez une archive de la manière suivante :

$ cd ..
$ mv ancien ancien-module1-corrections_bogues
$ tar -cvzf ancien-module1-corrections_bogues.tar.gz ancien-module1-corrections_bogues
$ rm -rf ancien-module1-corrections_bogues

	Astuce
	La commande « cvs up » peut prendre l’option « -d » pour créer de nouveaux répertoires et l’option « -P » pour supprimer les répertoires vides.

	Astuce
	Vous pouvez ne vérifier qu’un sous-répertoire de « module1 » en indiquant son nom comme, par exemple, « cvs co module1/sous-répertoire ».

Pour obtenir les derniers fichiers du CVS, utilisez « tomorrow » comme suit :

$ cvs ex -D tomorrow nom_module

Ajoutez l’alias « mx » à un projet CVS (serveur local) de la manière suivante :

$ export CVSROOT=/srv/cvs/projet
$ cvs co CVSROOT/modules
$ cd CVSROOT
$ echo "mx -a module1" >>modules
$ cvs ci -m "mx est maintenant un alias de module1"
$ cvs release -d .

Vous pouvez maintenant vérifier « module1 » (alias : « mx ») depuis le CVS vers le répertoire « new » de la manière suivante :

$ cvs co -d nouveau mx
$ cd nouveau

	Note
	Afin de pouvoir effectuer la procédure précédente, vous devrez avoir les permissions d’accès aux fichiers appropriées.

Lorsque vous vérifiez des fichiers du CVS, leur bit d’autorisation en exécution est conservé.

Si vous rencontrez des problèmes de droits d’exécution avec un fichier récupéré, par exemple « nom_fichier », modifiez-en les permissions dans le répertoire correspondant du dépôt CVS par ce qui suit afin de corriger ce problème :

# chmod ugo-x nom_de_fichier

Actuellement, le paquet subversion ne configure pas le dépôt, on doit donc le faire manuellement. Un emplacement possible pour le dépôt se trouve en « /srv/svn/projet ».

Créez un répertoire de la manière suivante :

# mkdir -p        /srv/svn/projet

Créez la base de données du dépôt comme suit :

# svnadmin create /srv/svn/projet

Si vous n’avez accès au dépôt de Subversion que par un serveur Apache2, il vous suffira de ne rendre le dépôt accessible en écriture que par le serveur WWW de la manière suivante :

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

Ajouter (ou décommenter) ce qui suit dans « /etc/apache2/mods-available/dav_svn.conf » afin de permettre l’accès au dépôt avec une authentification de l’utilisateur.

<Location /projet>
  DAV svn
  SVNPath /srv/svn/projet
  AuthType Basic
  AuthName "Dépôt subversion"
  AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
</LimitExcept>
</Location>

Créer un fichier d’authentification des utilisateurs avec la commande suivante :

# htpasswd2 -c /etc/subversion/passwd nom_utilisateur

Redémarrez Apache2.

Votre nouveau dépôt Subversion est accessible à l’URL « http://localhost/projet » et « http://example.com/projet » depuis svn(1) (en supposant que l’URL du serveur web est « http://example.com/ »).

Ce qui suit configure le dépôt Subversion pour un accès local par un groupe, projet, par exemple :

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

Votre nouveau dépôt Subversion est accessible aux utilisateurs locaux appartenant au groupe projetà l’URL « file:///localhost/srv/svn/projet » ou « file:///srv/svn/projet » depuis svn(1) . Vous devrez lancer des commandes comme svn, svnserve, svnlook et svnadmin avec « umask 002 » afin de permettre l’accès au groupe.

Un dépôt Subversion accessible à un groupe se trouve pour SSH à l’URL « example.com:/srv/svn/projet », vous pouvez y accéder avec svn(1) à l’URL « svn+ssh://example.com:/srv/svn/projet".

Afin de compenser le manque de branches et d’étiquettes, de nombreux projets utilisent une arborescence de répertoires semblable à la suivante pour Subversion :

  ----- module1
    |   |-- branches
    |   |-- tags
    |   |   |-- version-1.0
    |   |   `-- version-2.0
    |   |
    |   `-- trunk
    |       |-- fichier1
    |       |-- fichier2
    |       `-- fichier3
    |
    `-- module2

	Astuce
	Vous devez utiliser la commande « svn copy … » pour marquer les branches et les étiquettes. Cela permet de s’assurer que Subversion enregistre correctement l’historique de modification des fichiers et économise l’espace disque.

Créez un nouvel emplacement d’arborescence locale des sources dans « ~/chemin/vers/module1 » par la commande suivante :

$ mkdir -p ~/chemin/vers/module1; cd ~/chemin/vers/module1

Mettez des fichiers dans la nouvelles arborescence locale de sources se trouvant en « ~/chemin/vers/module1 ».

Importez-le dans Subversion avec les paramètres suivants :

$ cd ~/chemin/vers/module1
$ svn import file:///srv/svn/projet/module1/trunk -m "Lancement module1"
$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Version-initiale

ou encore, comme suit :

$ svn import ~/chemin/vers/module1 file:///srv/svn/projet/module1/trunk -m "Lancement module1"
$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Version-initiale

	Astuce
	Vous pouvez remplacer des formats d’URL comme « file:///… » par d’autres formats d’URL comme «  http://… » et « svn+ssh://… ».

Voici un exemple typique de flux de travail utilisant Subversion avec son client natif.

	Astuce
	Les commandes du client proposées par le paquet git-svn peuvent proposer un mode d’utilisation de remplacement pour Subversion en utilisant la commande git. Consultez Section 10.6.4, « Git pour le dépôt Subversion ».

Vérifiez de la manière suivante tous les modules disponibles depuis le projet pointé par l’URL « file:///srv/svn/projet » :

$ svn list file:///srv/svn/projet
module1
module2
...

Récupérez « module1/trunk » dans un répertoire « module1 » comme suit :

$ cd ~/chemin/vers
$ svn co file:///srv/svn/projet/module1/trunk module1
$ cd module1

Effectuez les modifications de contenu au besoin.

Vérifiez les modifications par un équivalent de « diff -u [repository] [local] » de la manière suivante :

$ svn diff

Vous-vous apercevez que vous avez cassé sévèrement un fichier appelé « fichier_à_restaurer » mais que les autres fichiers sont corrects.

Écrasez le fichier « fichier_a_annuler » avec une nouvelle copie propre depuis Subversion comme suit :

$ svn revert fichier_a_annuler

Enregistrez l’arbre local des sources mis à jour vers Subversion comme suit :

$ svn ci -m "Décrire les modifications"

Créez et ajoutez le fichier « fichier_a_ajouter » dans Subversion comme suit :

$ vi fichier_a_ajouter
$ svn add fichier_a_ajouter
$ svn ci -m "fichier_a_ajouter ajouté"

Fusionnez la dernière version depuis Subversion comme suit :

$ svn up

Recherchez les lignes commençant par « C filename » qui indiquent des modifications en conflit.

Recherchez le code non modifié, par exemple « nom_fichier.r6 », « nom_fichier.r9 » et « nom_fichier.mien ».

Recherchez « <<<<<<< » et « >>>>>>> » dans les fichiers qui indiquent des conflits de modifications.

Au besoin, éditez les fichiers pour résoudre les conflits.

Ajoutez l’étiquette de version (« release tag« ») « Version-1 » comme suit :

$ svn ci -m "dernier « commit » pour la Release-1"
$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Release-1

Poursuivez l’édition.

Supprimez l’étiquette de version « Version-1  » comme suit :

$ svn rm file:///srv/svn/projet/module1/tags/Release-1

Récupérez les modifications depuis Subversion comme suit :

$ svn ci -m "vraiment le dernier commit pour Release-1"

Ajoutez de nouveau la balise « Version-1 » depuis la version mise à jour de HEAD de trunk de Subversion comme suit :

$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Version-1

Créez une branche dont le chemin est « module1/branches/Release-initial-bugfixes » depuis la version initiale pointée par le chemin « module1/tags/Release-initial » et récupérez-le vers le répertoire « ~/chemin/vers/ancien » comme suit :

$ svn cp file:///srv/svn/projet/module1/tags/Version-initiale file:///srv/svn/projet/module1/branches/Version-initale-corrections-de-bogues
$ cd ~/chemin/vers
$ svn co file:///srv/svn/projet/module1/branches/Version-initiale-corrections-de-bogues ancien
$ cd ancien

	Astuce
	Utilisez « module1/trunk@{2005-12-20} » (format de date ISO 8601) plutôt que « module1/tags/Release-initial » pour indiquer une date particulière comme point de branche.

Travaillez sur cet arbre de sources local pointant vers la branche « Version-initiale-corrections-de-bogues » qui est basée sur la version initiale.

Travaillez vous-même sur cette branche… jusqu’à ce que quelqu’un d’autre rejoigne cette branche « Version-initiale-corrections-de-bogues ».

Effectuez la synchronisation avec les fichiers de cette branche modifiés par d’autres comme suit :

$ svn up

Au besoin, éditez les fichiers pour résoudre les conflits.

Récupérez les modifications depuis Subversion comme suit :

$ svn ci -m "récupérés dans cette branche"

Mettez à jour l’arborescence local avec HEAD de trunk de la manière suivante :

$ svn switch file:///srv/svn/projet/module1/trunk

Mettez à jour l’arborescence locale (contenu = HEAD de trunk) en fusionnant depuis la branche « Version-initiale-corrections-de-bogues » par ce qui suit :

$ svn merge file:///srv/svn/projet/module1/branches/Version-initiale-corrections-de-bogues

Corrigez les conflits avec l’éditeur.

Récupérez les modifications depuis Subversion comme suit :

$ svn ci -m "Version-initiale-corrections-de-bogues fusionnée"

Réalisez une archive de la manière suivante :

$ cd ..
$ mv ancien ancien-module1-corrections_bogues
$ tar -cvzf ancien-module1-corrections_bogues.tar.gz ancien-module1-corrections_bogues
$ rm -rf ancien-module1-corrections_bogues

	Astuce
	Vous pouvez remplacer des formats d’URL comme « file:///… » par d’autres formats d’URL comme «  http://… » et « svn+ssh://… ».

	Astuce
	Vous pouvez ne vérifier (« checkout ») qu’un sous-répertoire de « module1 » en indiquant son nom comme, par exemple, « svn co file:///srv/svn/projet/module1/trunk/sous-répertoire module1/sous-répertoire », etc.