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 référentiel, Subversion vous fournit des commandes pour fusionner ces changements dans votre répertoire de travail.

Une copie de travail contient aussi quelques fichiers supplémentaires, créés et entretenus par Subversion, pour l'aider à effectuer ces commandes. Particulièrement chaque répertoire dans votre copie de travail contient un sous-répertoire nommé .svn, aussi connu comme le répertoire administratif de la copie de travail. Les fichiers de chaque répertoire administratif aident Subversion à reconnaître quels fichiers contiennent des changements non publiés et quels fichiers sont périmés par rapport au travail des autres.

Un référentiel 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 référentiel. Dans cette optique, la copie de travail d'un utilisateur correspondra d'habitude à un sous-arbre particulier du référentiel.

Par exemple, supposons que vous avez un référentiel contenant deux projets d'application.

Figure 2.6. Le système de fichiers du référentiel

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

Pour obtenir une copie de travail, vous devez extraire une sous-arborescence du référentiel. (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 référentiel.

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 référentiel ; 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 référentiel, pour décider quels fichiers doivent être actualisés.

Les référentiels 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 référentiel, 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 référentiels 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 référentiel :

file:///X:/chemin/vers/référentiel
...
file:///X|/chemin/vers/référentiel
...

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 référentiel FSFS via un partage réseau, mais vous ne pouvez pas avoir accès à un référentiel 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 référentiel, 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 référentiel 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 référentiel 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 référentiel 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 référentiel ressemble après chaque livraison.

Figure 2.7. Le référentiel

Il est important de noter que les copies de travail ne correspondent pas toujours à une seule révision dans le référentiel ; elles peuvent contenir des fichiers de plusieurs révisions différentes. Par exemple, supposez que vous extrayiez une copie de travail d'un référentiel 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 référentiel. 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 référentiel, 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 référentiel.

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 référentiel, Subversion peut dire dans lequel des quatre états suivants se trouve un fichier de travail :