Subversion en action

Copies de travail

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.

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. 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. Avant la version 1.7, Subversion maintenait le 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 un enfant immédiat de 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 avez un dépôt contenant deux projets d'application.

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

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 (CdT), il faut extraire une partie de l'arbordescence 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 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.

URL de dépôt

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 :

Tableau 2.1. URL d'accès au dépôts

SchémaMéthode d'accès
file:// Accès direct au dépôt sur disque local ou réseau.
http:// Accès via le protocole WebDAV à un serveur Apache avec Subversion.
https:// Même chose que http://, mais avec cryptage SSL.
svn:// Accès TCP/IP non authentifié via un protocole personnalisé à un serveur svnserve.
svn+ssh:// Accès TCP/IP authentifié, crypté via un protocole personnalisé à un serveur svnserve.

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 certaines raisons :

  • Vous donnez un accès direct en écriture à tous les utilisateurs, ils pourraient donc accidentellement supprimer ou corrompre le système du fichier du dépôt.

  • Tous les protocoles de partage de fichiers en réseau ne supportent pas le verrouillage que requière Subversion. Un beau jour, vous découvrirez que votre dépôt a été sournoisement corrompu.

  • Vous devez paramétrer les permissions d'accès de la bonne façon. SAMBA est particulièrement difficile à cet égard.

  • Si un utilisateur installe une nouvelle version du client qui met à jour le format du dépôt, tous les autres seront alors dans l'incapacité d'accéder au dépôt jusqu'à ce qu'ils mettent eux aussi leur client à la nouvelle version.

Révisions

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

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.

Comment les copies de travail suivent le dépôt

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

  • sur quelle révision votre fichier de travail est basé (cela s'appelle la révision de travail du fichier), et

  • un enregistrement d'horodatage quand la copie locale a été mise à jour en dernier par le dépôt.

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

Inchangé et courant

Le fichier est inchangé dans le répertoire de travail et aucun changement sur ce fichier n'a été livré au dépôt depuis sa révision de travail. Une livraison du fichier ne fera rien et une mise à jour du fichier ne fera rien.

Changé localement et courant

Le fichier a été changé dans le répertoire de travail et aucun changement sur ce fichier n'a été livré au dépôt depuis sa révision de base. Il y a des changements locaux qui n'ont pas été livrés au dépôt, ainsi une livraison du fichier réussira à publier vos changements et une mise à jour du fichier ne fera rien.

Inchangé et périmé

Le fichier n'a pas été changé dans le répertoire de travail, mais il a été changé dans le dépôt. Le fichier devrait être mis à jour éventuellement, pour l'actualiser avec la révision publique. Une livraison du fichier ne fera rien et une mise à jour du fichier intègrera les derniers changements dans votre copie de travail.

Changé localement et périmé

Le fichier a été modifié dans le répertoire de travail, et dans le dépôt. Une livraison du fichier échouera avec une erreur périmé. Le fichier devrait d'abord être mis à jour ; la commande mise à jour essayera de fusionner les deux versions. Si Subversion réussit pas à faire correctement la fusion, il laisse l'utilisateur résoudre le conflit.