Subversion implémente le concept de dépôt comme tout autre logiciel de gestion de versions moderne. Contrairement à une copie de travail, un dépôt Subversion est une entité abstraite qui ne peut être manipulée pratiquement que par les bibliothèques et les propres outils de Subversion. Comme la plupart des interactions d'un utilisateur de Subversion se font par l'intermédiaire du client Subversion et qu'elles ont lieu dans le contexte de la copie de travail, ce livre traite en une grande partie de la copie de travail et des actions que l'on peut y appliquer. Pour les détails du dépôt, vous pouvez cependant vous référer au Chapitre 5, Administration d'un dépôt.

Avertissement

Dans Subversion, l'entité que possède chaque utilisateur du logiciel — le répertoire des fichiers suivis en versions ainsi que les métadonnées qui permettent au système de tracer les données et de communiquer avec le serveur — s'appelle la copie de travail. Bien que d'autres logiciels de gestion de versions utilisent le terme de « dépôt » pour l'entité côté client, c'est à la fois incorrect et une source fréquente de confusion d'utiliser ce terme dans ce sens là dans le contexte de Subversion. Les copies de travail sont abordées plus loin, dans la section intitulée « Copies de travail ».

Une opération svn commit propage (c'est-à-dire communique au serveur) les modifications d'un nombre quelconque de fichiers et de répertoires en une seule opération atomique. Par opération atomique, nous entendons que, soit toutes les modifications sont prises en compte par le dépôt, soit rien n'est pris en compte. Subversion essai d'être robuste dans ce concept d'atomicité, même en cas de plantage du programme, du système, de problèmes réseau ou d'actions de la part des autres utilisateurs.

Chaque fois que le dépôt accepte une propagation (c'est-à-dire une opération svn commit), il crée un nouvel état de l'arborescence du système de fichiers que l'on appelle révision. À Chaque révision est associé un entier naturel unique, immédiatement supérieur à l'entier associé à la révision précédente. La révision initiale d'un dépôt nouvellement créé à pour numéro 0 et n'est constituée que d'un répertoire racine vide.

La Figure 1.6, « L'évolution de l'arborescence au cours du temps » illustre une manière intéressante de se représenter le dépôt. Imaginez un tableau de numéros de révisions, commençant à zéro et s'étirant de la gauche vers la droite. À Chaque numéro de révision est suspendue une arborescence du système de fichiers, qui est une photo, un « instantané » (snapshot en anglais) du dépôt prise après une propagation.

Figure 1.6. L'évolution de l'arborescence au cours du temps

les logiciels côté client de Subversion utilisent des URL pour identifier les fichiers et répertoires suivis en versions dans les dépôts Subversion. Pour leur grande partie, ces URL utilisent la syntaxe standard, permettant de spécifier le nom du serveur et le numéro de port directement dans l'URL.

Les URL de dépôts Subversion ne se limitent pas au domaine http://. Comme Subversion permet à ses clients de dialoguer de différentes manières avec les dépôts, les URL utilisées pour se connecter diffèrent subtilement en fonction du protocole employé. La Tableau 1.1, « Les différents motifs d'URL pour l'accès aux dépôts » décrit la correspondance entre les différents motifs d'URL et les méthodes d'accès aux dépôts. Pour plus de détails sur les options du serveur Subversion, reportez-vous au Chapitre 6, Configuration du serveur.

La gestion des URL par Subversion possède quelques particularités qu'il convient de noter. Par exemple, les URL contenant la méthode d'accès file:// (utilisée pour les dépôts locaux) doivent spécifier, par convention, soit le nom de serveur localhost, soit pas de nom de serveur :

D'autre part, les utilisateurs du procédé file:// sur les plateformes Windows doivent se servir d'une syntaxe qui est un « standard » officieux pour accéder à leurs dépôts se trouvant sur la même machine mais sur un disque différent du disque de travail habituel du client. Les deux syntaxes de chemin d'URL suivantes fonctionnent, X étant le disque sur lequel le dépôt se trouve :

Remarquez qu'une URL utilise des barres obliques (/) alors que la forme native (non-URL) d'un chemin sous Windows utilise des barres obliques inversées (\). Notez aussi que, dans la seconde syntaxe, vous devez entourer l'URL de guillemets pour éviter que la barre verticale ne soit interprétée comme un symbole de redirection (un « pipe »).

Note

Les URL Subversion file:// ne peuvent pas être utilisées dans un navigateur web classique de la même façon qu'une URL file:// habituelle. Lorsque vous essayez de visualiser une URL file:// dans un navigateur web classique, il lit et affiche le contenu du fichier situé à cet emplacement en interrogeant directement le système de fichiers. Cependant, les ressources de Subversion existent dans un système de fichier virtuel (cf. la section intitulée « Couche dépôt ») et votre navigateur ne comprend pas comment interagir avec ce système de fichiers.

Il faut noter que le client Subversion encode automatiquement les URL en cas de besoin, exactement comme le fait un navigateur web. Par exemple, l'URL http://host/path with space/project/españa — qui contient à la fois des espaces et des caractères non ASCII— est automatiquement interprétée par Subversion comme si vous aviez fourni http://host/path%20with%20space/project/espa%C3%B1a. Si l'URL contient des espaces, prenez bien soin de les placer entre guillemets dans la ligne de commande afin que le shell traite le tout comme un unique argument du programme.

Il existe aussi une exception à la gestion des URL par Subversion qui s'applique à la gestion des chemins locaux dans beaucoup de contextes. Si le dernier élément de l'URL ou du chemin contient le signe arobase (@), vous devez utiliser une syntaxe particulière, décrite dans la section intitulée « Révisions pivots et révisions opérationnelles », afin que Subversion prenne proprement en compte l'adresse de cette ressource.

Dans Subversion 1.6, une nouvelle notation, dite syntaxe avec chapeau (^) a été introduite comme raccourci pour « l'URL du répertoire racine du dépôt ». Par exemple, vous pouvez utiliser ^tags/gros-sandwich pour désigner l'URL du répertoire /tags/gros-sandwich à la racine du dépôt. Une telle URL est appelée URL relative au dépôt. Remarquez que cette syntaxe d'URL ne fonctionne que si votre répertoire de travail est une copie de travail, le client texte interactif récupérant l'URL de la racine du dépôt dans les métadonnées de la copie de travail. Notez aussi que lorsque vous voulez faire référence précisément au répertoire racine du dépôt, vous devez utiliser ^/ (avec la barre oblique terminale) et non simplement ^. Les utilisateurs sous Windows ne doivent pas oublier que le caret est un caractère d'échappement pour ce système. En conséquence, vous devez utiliser un double caret ^^ si votre client Subversion tourne sur une machine Windows.

Une copie de travail Subversion est une arborescence classique de répertoires de votre système local, contenant un ensemble de fichiers. Vous pouvez éditer ces fichiers comme vous le voulez et, s'il s'agit de code source, vous pouvez compiler votre programme à partir de ceux-ci de la façon habituelle. Votre copie de travail est votre espace de travail personnel privé : Subversion n'y incorpore jamais les changements d'autres personnes ni ne rend jamais disponibles vos propres changements à d'autres personnes tant que vous ne lui demanderez pas explicitement de le faire. Vous pouvez même avoir plusieurs copies de travail d'un même projet.

Après que vous ayez apporté quelques modifications aux fichiers de votre copie de travail et vérifié qu'elles fonctionnent correctement, Subversion vous fournit des commandes pour « publier » vos changements vers les autres personnes qui travaillent avec vous sur votre projet (en les transmettant au dépôt). Si d'autres personnes publient leurs propres modifications, Subversion vous fournit des commandes pour fusionner ces changements dans votre copie de travail (en les obtenant du dépôt). Remarquez que le dépôt central joue le rôle d'intermédiaire pour les changements de tout le monde dans Subversion ; les modifications ne passent pas directement d'une copie de travail à une autre copie de travail dans le processus classique.

Une copie de travail contient également quelques fichiers supplémentaires, créés et gérés par Subversion, pour l'aider à effectuer ces opérations. En particulier, chaque copie de travail contient un sous-répertoire nommé .svn, aussi connu sous l'appellation de répertoire administratif de votre copie de travail. Les fichiers de ce répertoire administratif permettent à Subversion d'identifier quels fichiers contiennent des modifications non-publiées et quels fichiers sont périmés vis-à-vis du travail des autres personnes.

Note

Avant la version 1.7, Subversion plaçait un répertoire .svn dans chaque sous-répertoire géré en versions de la copie de travail. Subversion 1.7 utilise une approche complètement nouvelle pour stocker, suivre et travailler avec les métadonnées, et le changement le plus visible de cette approche est qu'il n'existe dans la copie de travail qu'un seul sous-répertoire .svn situé à la racine de la copie de travail.

Actions de base sur la copie de travail

Un dépôt Subversion contient bien souvent les fichiers (ou code source) de plusieurs projets ; habituellement, chaque projet est un sous-répertoire de l'arborescence du système de fichiers du dépôt. Dans cette situation, la copie de travail d'un utilisateur correspond à une sous-arborescence particulière du dépôt.

Par exemple, supposons que votre dépôt contienne deux projets logiciels, paint et calc. Chaque projet réside dans son propre sous-répertoire racine, comme indiqué dans la Figure 1.7, « Système de fichiers du dépôt ».

Figure 1.7. Système de fichiers du dépôt

Pour obtenir une copie de travail, vous devez extraire une sous-arborescence du répertoire (le terme « extraire », check out en anglais, peut vous faire penser que cela a quelque chose à voir avec verrouiller ou réserver des ressources, mais ce n'est pas le cas ; cela crée simplement pour vous une copie privée du projet). Par exemple, si vous extrayez /calc, vous obtenez une copie de travail qui ressemble à ceci :

$ svn checkout http://svn.exemple.com/depot/calc
A    calc/Makefile
A    calc/entier.c
A    calc/bouton.c
Révision 56 extraite.
$ ls -A calc
Makefile  bouton.c entier.c .svn/
$

Les lettres A qui s'affichent dans la marge de gauche indiquent que Subversion est en train d'ajouter des éléments dans votre copie de travail. Vous avez désormais votre copie personnelle du répertoire /calc du dépôt, avec une entrée supplémentaire, .svn, qui contient des informations complémentaires nécessaires à Subversion, comme évoqué précédemment.

Supposons que vous fassiez des modifications à bouton.c. Comme le répertoire .svn se souvient de la date de modification et du contenu du fichier original, Subversion peut en déduire que vous avez modifié le fichier. Néanmoins, Subversion ne rend pas vos modifications publiques tant que vous ne lui dites pas de le faire. L'action de publication de vos modifications est plus communément appelée propagation (« commit » ou check in en anglais et, parfois, archivage ou livraison en français) des modifications au sein du dépôt.

Pour rendre publiques vos modifications, vous pouvez utiliser la commande Subversion svn commit :

$ svn commit bouton.c -m "Coquille corrigée dans bouton.c."
Ajout        bouton.c
Transmission des données .
Révision 57 propagée.
$

À présent, vos modifications de bouton.c ont été propagées au sein du dépôt, avec un commentaire décrivant ces changements (« vous avez corrigé une coquille »). Si un autre utilisateur extrait une copie de travail de /calc/, il verra vos modifications dans la dernière version du fichier.

Supposons que vous ayez une collaboratrice, Sally, qui a extrait une copie de travail de /calc en même temps que vous. Lorsque vous propagez votre modification de bouton.c, la copie de travail de Sally reste inchangée ; Subversion ne modifie les copies de travail qu'à la demande des utilisateurs.

Pour mettre son projet à jour, Sally peut demander à Subversion de mettre à jour (update en anglais) sa copie de travail, en utilisant la commande svn update. Cela va intégrer vos modifications dans sa copie de travail, ainsi que celles qui ont été envoyées par d'autres personnes depuis qu'elle l'avait extraite.

$ pwd
/home/sally/calc

$ ls -A
Makefile bouton.c entier.c .svn/
$ svn update
U    bouton.c
Actualisé à la révision 57.
$

En sortie, la commande svn update indique que Subversion a mis à jour le contenu de bouton.c. Remarquez que Sally n'a pas eu besoin de spécifier quels fichiers devaient être mis à jour ; Subversion utilise les informations contenues dans le répertoire .svn, ainsi que d'autres informations en provenance du dépôt, pour décider quels fichiers doivent être mis à jour.