Vous a déjà lu au sujet des copies de travail ; maintenant nous allons vous montrer comment le client Subversion les crée et les utilise.

Une copie de travail de Subversion est une arborescence de répertoires ordinaire sur votre système local, contenant une collection de fichiers. Vous pouvez éditer ces fichiers comme vous le souhaitez, et si ce sont des fichiers de code source, vous pouvez compiler votre programme de la façon habituelle. Votre copie de travail est votre propre secteur de travail privé : Subversion n'incorporera jamais les changements d'autres personnes, ni ne rendra vos propres changements disponibles aux autres, jusqu'à ce que vous lui disiez explicitement de le faire.

Après avoir fait des changements dans votre copie de travail et avoir vérifié qu'ils fonctionnent correctement, Subversion vous fournit des commandes pour publier vos changements et ainsi les rendre disponibles aux les autres personnes travaillant avec vous sur le projet. Si d'autres personnes publient leurs changements dans le dépôt, Subversion vous fournit des commandes pour fusionner ces changements dans votre répertoire de travail.

A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, your working copy contains a subdirectory named .svn, also known as the working copy administrative directory. The files in this administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work. Prior to 1.7 Subversion maintained .svn administrative subdirectories in every versioned directory of your working copy. Subversion 1.7 takes a completely different approach and each working copy now has only one administrative subdirectory which is an immediate child of the root of that working copy.

Un dépôt typique de Subversion contient souvent les fichiers (ou le code source) pour plusieurs projets ; d'habitude, chaque projet est un sous-répertoire dans l'arborescence du système de fichiers du dépôt. Dans cette optique, la copie de travail d'un utilisateur correspondra d'habitude à un sous-arbre particulier du dépôt.

Par exemple, supposons que vous avez un dépôt contenant deux projets d'application.

Figure 2.6. Le système de fichiers du dépôt

En d'autres termes, la racine du dépôt a deux sous-répertoires : paint et calc.

Pour obtenir une copie de travail, vous devez extraire une sous-arborescence du dépôt. (Le terme extraire peut faire penser à un quelconque verrouillage ou à une réservation des ressources, mais il n'en est rien ; il crée simplement une copie privée du projet pour vous).

Supposons que vous faites des changements sur button.c. Puisque le répertoire .svn se rappelle la date de modification et le contenu original du fichier, Subversion peut dire que vous avez modifié le fichier. Cependant, Subversion ne rend pas vos changements publics jusqu'à ce que vous le lui disiez explicitement. L'acte de publier vos changements est plus communément appelé livrer (ou valider) les changements au dépôt.

Pour publier vos changements aux autres, vous pouvez utiliser la commande de Subversion livrer.

Maintenant vos changements sur button.c ont été livrés au dépôt ; si un autre utilisateur extrait une copie de travail de /calc, il verra vos changements dans la dernière version du fichier.

Supposons que vous avez une collaboratrice, Sally, qui a extrait une copie de travail de /calc en même temps que vous. Quand vous livrez votre changement sur button.c, la copie de travail de Sally est laissée inchangée ; Subversion modifie seulement les copies de travail à la demande de l'utilisateur.

Pour actualiser son projet, Sally peut demander à Subversion de mettre à jour sa copie de travail, en utilisant la commande de Subversion mettre à jour. Cela incorporera vos changements dans sa copie de travail, en même temps que d'autres qui ont été livrés depuis qu'elle l'a extrait.

Notez que Sally n'a pas dû spécifier les fichiers à mettre à jour; Subversion utilise l'information dans le répertoire .svn et la nouvelle information dans le dépôt, pour décider quels fichiers doivent être actualisés.

Les dépôts de Subversion peuvent être accédés par beaucoup de méthodes différentes - sur le disque local, ou par des protocoles de réseau divers. Un emplacement de dépôt, cependant, est toujours une URL. Le schéma d'URL indique la méthode d'accès :

Pour la plupart, les URL de Subversion utilisent la syntaxe standard, autorisant la définition des noms serveur et des numéros de port dans l'URL. La méthode d'accès file:// est normalement utilisée pour les accès locaux, bien qu'elle puisse être utilisée avec des chemins UNC pour un hôte non local. L'URL prend donc la forme file://nomhote/chemin/vers/referentiel. Pour la machine locale, la partie nomhote de l'URL doit être soit absente, soit localhost. Pour cette raison, les chemins locaux apparaissent normalement avec trois slashs, file:///chemin/vers/referentiel.

Ainsi, les utilisateurs du système de fichier file: sur les plate-formes Windows devront utiliser une syntaxe « standard » non-officielle pour avoir accès aux dépôts qui sont sur la même machine, mais sur un disque différent du disque de travail. Les deux syntaxes de d'URL suivantes marcheront ; X est le disque sur lequel est hébergé le dépôt :

file:///X:/chemin/vers/dépôt
...
file:///X|/chemin/vers/dépôt
...

Notez qu'une URL utilise des slashs ordinaires bien que la forme native d'un chemin (non-URL) utilise des antislashs sous Windows.

Vous pouvez sans risque avoir accès à un dépôt FSFS via un partage réseau, mais vous ne pouvez pas avoir accès à un dépôt BDB de cette façon.

Une opération svn commit peut publier les changements de n'importe quel nombre de fichiers et de répertoires comme une seule transaction atomique. Dans votre copie de travail, vous pouvez changer le contenu des fichiers, créer, supprimer, renommer et copier des fichiers et des répertoires et ensuite livrer le jeu complet de changements comme une unité.

Dans le dépôt, chaque livraison est traitée comme une transaction atomique : tous les changements de la livraison ont lieu, ou aucun n'a lieu. Subversion essaye de conserver cette atomicité face aux plantages du programme, pannes système, problèmes de réseau et autres actions utilisateur.

Chaque fois que le dépôt accepte une livraison, cela crée un nouvel état de l'arborescence du système de fichiers, appelé une révision. À chaque révision est assignée un entier naturel unique, plus grand que le numéro de la révision précédente d'une unité. La révision initiale d'un dépôt récemment créé est numérotée zéro et ne consiste en rien d'autre qu'un répertoire racine vide.

Une façon agréable de visualiser le dépôt est une série d'arbres. Imaginez un tableau de numéros de révision, commençant à 0, s'étirant de gauche à droite. Chaque numéro de révision a un arbre du système de fichiers s'accrochant au-dessous de lui et chaque arbre est un « instantané » de la façon à laquelle le dépôt ressemble après chaque livraison.

Figure 2.7. Le Dépôt

Il est important de noter que les copies de travail ne correspondent pas toujours à une seule révision dans le dépôt ; elles peuvent contenir des fichiers de plusieurs révisions différentes. Par exemple, supposez que vous extrayiez une copie de travail d'un dépôt dont la révision la plus récente est 4 :

calc/Makefile:4
     integer.c:4
     button.c:4

À l'heure actuelle, ce répertoire de travail correspond exactement à la révision 4 dans le dépôt. Cependant, supposez que vous faites un changement sur button.c et que vous livrez ce changement. En admettant qu'aucune autre livraison n'ait eu lieue, votre livraison créera la révision 5 du dépôt, et votre copie de travail ressemblera maintenant à cela :

calc/Makefile:4
     integer.c:4
     button.c:5

Supposons que, à ce point, Sally livre une modification sur integer.c, créant la révision 6. Si vous utilisez svn update pour actualiser votre copie de travail, elle ressemblera alors à ceci :

calc/Makefile:6
     integer.c:6
     button.c:6

Les changements de Sally sur integer.c apparaîtront dans votre copie de travail et votre changement seront toujours présent dans button.c. Dans cet exemple, le texte Makefile est identique dans des révisions 4, 5 et 6, mais Subversion marquera votre copie de travail de Makefile avec la révision 6 pour indiquer qu'il est toujours d'actualité. Ainsi, après avoir fait une mise à jour propre au sommet de votre copie de travail, elle correspondra généralement exactement à une révision dans le dépôt.

Pour chaque fichier dans un répertoire de travail, Subversion enregistre deux informations essentielles dans le secteur administratif .svn/ :

Avec ces informations, en parlant au dépôt, Subversion peut dire dans lequel des quatre états suivants se trouve un fichier de travail :