Vous avez 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.

Une copie de travail contient aussi quelques fichiers supplémentaires, créés et entretenus par Subversion, pour l'aider à effectuer ces commandes. En particulier, 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 ce 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. Avant la version 1.7, Subversion maintenait un répertoire administratif .svn dans chaque répertoire versionné de votre copie de travail. Subversion 1.7 adopte une approche complètement différente et chaque copie de travail a maintenant un seul répertoire administratif, qui est situé immédiatement sous la racine de cette copie de travail.

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 ayez 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.

Afin d'obtenir une copie de travail, il faut extraire une partie de l'arborescence du dépôt. (Le terme anglais check out pourrait suggérer qu'il s'agit de verrouiller ou de réserver des ressources du dépôt, mais ce n'est pas le cas. Il s'agit simplement d'une copie privée, également appelé bac à sable, du projet pour l'utilisateur.)

Supposons que vous fassiez 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'action de publier vos changements est plus communément appelée 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 ayez 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 ne modifie les copies de travail qu'à 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 tous les 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/depots
...
file:///X|/chemin/vers/depots
...
      

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 accéder à un répertoire FSFS via un partage réseau, mais ce n'est pas recommandé pour plusieurs raisons :

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, supposons 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, supposons que vous fassiez un changement sur button.c et que vous livriez ce changement. En admettant qu'aucune autre livraison n'ait eu lieu, 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 sera toujours présent dans button.c. Dans cet exemple, le texte de 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 à jour. 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 :