Vous avez déjà vu ce qu'est une copie de travail; maintenant, nous allons vous montrer comment le client Subversion crée et utilise ces derniers.

Une copie de travail de Subversion est un répertoire ordinaire dans votre système de fichiers, qui contient un ensemble de fichiers. Vous pouvez éditer ces fichiers autant que vous le désirez, et, si ce sont des codes sources, vous pouvez compiler votre programme de manière habituelle. Votre copie de travail est votre espace privé de travail : Subversion n'incorporera jamais les changements d'autres personnes, ni ne mettra vos modifications à disposition des autres, tant que vous ne le faites pas explicitement.Vous pouvez de plus avoir plusieurs copies de travail du même projet.

Après avoir effectué quelques changements sur les fichiers dans votre copie de travail, et vérifié que tout marche correctement, Subversion vous donne la possibilité et les commandes pour “propager” vos changements pour les autres personnes travaillant avec vous sur le projet (en écrivant dans le dépôt). Si d'autres personnes propagent leurs propres changements, Subversion vous donne la possibilité, avec des commandes, de fusionner ces changements vers votre copie de travail. (en lisant dans le dépôt)

Une copie de travail contient quelques fichiers supplémentaires, créés et maintenus par Subversion, pour l'assister et répondre au mieux aux commandes que vous effectuez. En particulier, tous les répertoires contiennent un sous répertoire nommé .svn, qui est aussi appellé répertoire administratif de la copie de travail. Les fichiers contenus dans chaque répertoire administratif aident Subversion pour reconnaître les fichiers contenant des modifications encore non publiées, et marquent les fichiers qui sont dépassés, en respectant le travail des autres.

Un répertoire typique d'une arborescence de Subversion contient les fichiers (ou les codes sources), pour plusieurs projets; habituellement, chaque projet est contenu dans un sous-répertoire de l'arborescence du dépôt. Avec cette organisation, une copie de travail d'un utilisateur correspond souvent à une sous-arborescence du dépôt.

Par exemple, imaginons que nous avons un dépôt qui contient deux projets logiciels, paint et calc. Chaque projet dispose de sa propre arborescence de fichiers, comme le montre la Figure 2.6, “Le système de fichier du dépôt”.

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

Pour avoir une copie de travail, vous devez check out des sous-repertoires du dépôt. (Le terme “check out” ressemble a quelque chose que l'on va verrouiller ou réserver de ressources, mais ce n'est pas le cas, cela permet juste de récupérer une nouvelle copie de travail pour vous.) Par exemple, si vous check out /calc, vous aurez une copie de travail qui va ressembler à ceci:

$ svn checkout http://svn.example.com/repos/calc
A  calc
A  calc/Makefile
A  calc/integer.c
A  calc/button.c

$ ls -A calc
Makefile  integer.c  button.c  .svn/

La lettre A indique que Subversion a ajouté un certain nombre d'éléments à votre copie de travail. Vous avez désormais votre propre copie de travail personnelle du répertoire /calc du dépôt, avec une entrée supplémentaire, le répertoire .svn— qui contient un certain nombre d'informations nécessaires à Subversion, comme mentionné précédemment.

Supposons que vous effectuiez des changements sur button.c. Puisque le répertoire .svn se souvient des dates de modifications et du contenu original, Subversion peut dire que vous avez modifié le fichier. Bien sur, Subversion ne va pas rendre publique vos modifications si vous ne lui demandez pas explicitement de le faire. L'acte de publication de vos modifications est habituellement et plus couramment désigné sous le nom de soumission des (ou appliquer les ) modifications au dépôt.

Pour publier vos changements et les rendre accessibles aux autres utilisateurs, vous devez utiliser la commande commit de Subversion:

$ svn commit button.c
Sending        button.c
Transmitting file data .
Committed revision 57.

Maintenant que vos changements sur button.c ont été appliqués au dépôt; si quelqu'un récupère une copie de travail de /calc, il verra/récupèrera les changements que vous avez soumis dans la dernière version du fichier.

Imaginons que votre collaborateur, Sally, ait récupéré une copie de travail en même temps que vous. Lorsque vous appliquez les changements au fichier button.c, le répertoire de travail de Sally n'est pas modifié; Subversion modifie les copies de travail à la demande de l'utilisateur uniquement.

Pour actualiser sa version du projet, Sally doit demander à Subversion de mettre à jour sa copie de travail, en utilisant la commande update de Subversion. Cela incorporera vos changements dans sa copie de travail, ainsi que tous les changements apportés et appliqués au dépôt depuis la dernière fois qu'elle a effectué une mise à jour.

$ pwd
/home/sally/calc

$ ls -A 
.svn/ Makefile integer.c button.c

$ svn update
U button.c

Les indications fournies par la commande svn update montrent que Subversion a mis à jour le contenu du fichier button.c. Remarquez que Sally n'a pas demandé quels fichiers mettre à jour; Subversion a utilisé pour cela les informations contenues dans son répertoire .svn, et les informations disponibles dans le dépôt, et effectué son choix en conséquence.

Effectuer un svn commit permet de publier les modifications de plusieurs fichiers et répertoires en une seule et unique transaction. Dans votre copie de travail, vous pouvez modifier, supprimer, déplacer, renommer et copier des fichiers et des répertoires, et ensuite, appliquer l'ensemble des changements sur le dépôt en une seule opération.

Dans le dépôt, chaque publication est traitée comme une transaction atomique : soit toutes les modifications réussissent et sont prises en compte, soit aucune n'est effectuée. Subversion essaie de garder au maximum cette atomicité, dans le cas d'un crash du programmme, du système, d'un problème réseau, ou n'importe quelle action utilisateur.

Chaque fois que le dépôt accepte un publication de fichier, cela crée un nouvel état dans l'arborescence de fichiers, appellé révision. À chaque révision est assigné un nombre entier unique, plus grand que celui de la révision précédente. La révision initiale, lorsque le projet vient d'être créé, est numérotée 0, et ne contient rien d'autre qu'un unique répertoire vide.

La Figure 2.7, “Le dépôt” illustre une bonne façon de se représenter le dépôt. Imaginez un tableau contenant les numéro de révision, qui s'étire de la gauche vers la droite. Chaque numéro de révision est associé à une arborescence de fichiers, et chaque arborescence de fichiers représente un “instantané” de l'état du dépôt après une publication.

Figure 2.7. Le dépôt

Il est important de bien comprendre qu'une copie de travail ne correspond pas toujours à une unique révision dans le dépôt; et peut contenir, par exemple, des fichiers issus de n'importe quelle révision. Par exemple, supposons que vous synchronisiez votre copie de travail avec la révision la plus récente, la 4:

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

A ce moment précis, la copie de travail correspond exactement à la révision 4 du dépôt. Maintenant, supposons que vous effectuiez des changements sur le fichier button.c, et que vous soumettiez ces changements au dépôt. En supposant qu'aucune autre soumission n'ait eu lieu, votre soumission crée la révision 5 du dépôt, et votre copie de travail va désormais ressembler à cela:

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

Supposons qu'à ce moment, Sally publie ses changements sur le fichier integer.c, créant par la même occasion la révision 6. Si vous utilisez la commande svn update pour mettre à jour votre copie de travail, alors vous obtiendrez ceci:

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

Les changements que Sally a effectués sur integer.c apparaissent désormais dans votre répertoire de travail, et vos changements seront toujours bien là dans button.c. Dans cet exemple, le texte du fichier Makefile est identique dans les révisions 4, 5, et 6, mais Subversion étiquette votre copie de travail de Makefile avec le numéro de révision 6, pour indiquer que c'est bien le fichier tel qu'il est actuellement. C'est pourquoi, après que vous ayez effectué un mise à jour proprement, au sommet de votre répertoire contenant la copie de travail, cette dernière correspond généralement exactement à la révision contenue dans le dépôt.

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

Avec ces informations, et avec les informations récupérées du dépôt, Subversion peut déterminer dans lequel des quatres états suivants un fichier de travail se trouve :

Tout ceci peut donner l'impression qu'il y a beaucoup de situations à prendre en compte, mais la commande svn status vous montre l'état de chaque élément contenu dans votre répertoire de travail. Pour plus d'informations sur cette commande, voir the section called “svn status”.

Voulant être le plus général, Subversion tente d'être le plus flexible possible. Une preuve de cette flexibilité est son habileté à avoir des copies de travail contenant des fichiers et des répertoires avec des numéros de révision de travail différents. Malheureusement, cette flexibilité tend à rendre confu le fonctionnement pour bon nombre de nouveaux utilisateurs. Si l'exemple précédent vous laisse perplexe, et que de manière générale, vous ne comprenez pas vraiment l'utilité de ces numéros de version mixtes, nous allons voir ici pourquoi ces fonctions existent, et comment en tirer parti.