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épertoire 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.

After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to publish your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository).

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.

To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you).

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 :

For the most part, Subversion's URLs use the standard syntax, allowing for server names and port numbers to be specified as part of the URL. The file:// access method is normally used for local access, although it can be used with UNC paths to a networked host. The URL therefore takes the form file://hostname/path/to/repos. For the local machine, the hostname portion of the URL is required to be either absent or localhost. For this reason, local paths normally appear with three slashes, file:///path/to/repos.

Also, users of the file:// scheme on Windows platforms will need to use an unofficially « standard » syntax for accessing repositories that are on the same machine, but on a different drive than the client's current working drive. Either of the two following URL path syntaxes will work where X is the drive on which the repository resides:

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 :