Pour avoir une vue d'ensemble des changements que vous avez effectués, utilisez la commande svn status. C'est certainement la commande Subversion que vous utiliserez le plus.

Astuce

Parce que l'affichage produit par la commande cvs status était tellement verbeux et parce que la commande cvs update ne faisait pas qu'une mise à jour mais affichait également l'état des changements effectués localement, la plupart des utilisateurs de CVS ont appris à utiliser cvs update pour propager leurs modifications. Dans Subversion, les opérations de mise-à-jour et d'examen des changements sont complètement séparées. Reportez-vous à la section intitulée « Distinction entre les commandes status et update » pour plus de détails.

Si vous lancez svn status sans argument à la racine de votre copie de travail, Subversion détecte toutes les modifications effectuées sur les fichiers et sur l'arborescence.

$ svn status
?       gribouillage.c
A       bazar/pognon
A       bazar/pognon/nouveau.h
D       bazar/vieux.c
M       machin.c

Dans le format d'affichage par défaut, svn status affiche sept colonnes de caractères, suivis par plusieurs espaces, suivis par un nom de fichier ou de dossier. La première colonne indique le statut du fichier ou du dossier et/ou son contenu. Les codes les plus utilisés sont :

Si vous spécifiez un chemin à svn status, vous obtenez uniquement les informations relatives à ce chemin :

$ svn status bazar/poisson.c
D      bazar/poisson.c

svn status possède aussi une option --verbose (-v) pour la rendre plus verbeuse : elle affiche alors le statut de tous les éléments de votre copie de travail, même ceux qui n'ont pas subi de modification :

 
$ svn status -v
M               44        23    sally     LISEZMOI
                44        30    sally     INSTALL
M               44        20    harry     machin.c
                44        18    ira       bazar
                44        35    harry     bazar/truite.c
D               44        19    ira       bazar/poisson.c
                44        21    sally     bazar/divers
A                0         ?     ?        bazar/divers/bitoniau.h
                44        36    harry     bazar/divers/tartempion.c

C'est la « version longue » de l'affichage de svn status. Les lettres de la première colonne ont la même signification que précédemment, mais la deuxième colonne indique le numéro de révision de travail de l'élément. Les troisième et quatrième colonnes indiquent le numéro de la révision dans laquelle a eu lieu le changement le plus récent et qui l'a effectué.

Aucune des commandes citées ci-dessus n'induit de connexion vers le dépôt : elles comparent les métadonnées de la zone administrative et les horodatages avec la copie de travail. Parfois, il peut être utile de voir quels éléments de la copie de travail ont été modifiés dans le dépôt depuis la dernière mise à jour de la copie de travail. À cette fin, svn status propose l'option --show-updates (-u) qui effectue une connexion au dépôt et ajoute les informations sur les éléments périmés :

$ svn status -u -v
M      *        44        23    sally     LISEZMOI
M               44        20    harry     machin.c
       *        44        35    harry     bazar/truite.c
D               44        19    ira       bazar/poisson.c
A                0         ?     ?        bazar/divers/bitoniau.h
État par rapport à la révision   46

Notez les deux astérisques : si vous lanciez la commande svn update, vous recevriez les changements relatifs à LISEZMOI et truite.c. Cela vous procure des informations particulièrement intéressantes, puisque l'un des éléments a fait l'objet de modifications de votre part (le fichier LISEZMOI) ; vous devez faire une mise à jour et récupérer les changements effectués sur LISEZMOI avant de propager les vôtres, sinon le dépôt rejettera votre propagation en la considérant comme périmée (le sujet est approfondi plus tard).

svn status peut afficher beaucoup plus d'informations sur les fichiers et dossiers de votre copie de travail que ce que nous venons de voir ici. Pour obtenir une description exhaustive de svn status et de ses modes d'affichage, lancez svn help status ou reportez-vous à svn status (stat, st) dans Guide de référence de svn : le client texte interactif.

La commande svn diff offre une autre façon d'examiner vos changements. En lançant la commande svn diff dans le dossier racine de votre copie de travail et sans argument, Subversion affiche les changements que vous avez apportés dans les fichiers lisibles par les humains de votre copie de travail. Il affiche ces changements au format diff unifié, un format qui décrit les changements par des « morceaux » (hunks ou snippets en anglais) du contenu des fichiers, où chaque ligne de texte est préfixée par un code sur un caractère : une espace signifie que la ligne n'a pas été modifiée ; un signe moins (-) signifie que la ligne a été supprimée du fichier ; et un signe plus (+) signifie que la ligne a été ajoutée au fichier. Dans le contexte de svn diff, les préfixes respectivement + et - montrent le contenu des lignes respectivement avant et après vos modifications.

Voici un exemple :

$ svn diff
Index: truc.c
===================================================================
--- machin.c	(révision 3)
+++ machin.c	(copie de travail)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>
 int main(void) {
-  printf("Soixante-quatre tranches de fromage...\n");
+  printf("Soixante-cinq tranches de fromage...\n");
 return 0;
 }
Index: LISEZMOI
===================================================================
--- LISEZMOI	(révision 3)
+++ LISEZMOI	(copie de travail)
@@ -193,3 +193,4 @@
+Pense-bête : passer au pressing.
Index: bazar/poisson.c
===================================================================
--- bazar/poisson.c	(révision 1)
+++ bazar/poisson.c	(copie de travail)
-Bienvenue dans le fichier 'poisson'.
-Plus d'informations seront disponibles prochainement.
Index: bazar/divers/machin.h
==================================================================
--- bazar/divers/bitoniau.h	(révision 8)
+++ bazar/divers/bitoniau.h	(copie de travail)
+Voici un nouveau fichier pour
+écrire sur les petites choses.

La commande svn diff produit ces lignes en comparant vos fichiers de travail aux copies « originales » en cache dans la zone administrative. Les fichiers marqués pour ajout sont affichés comme toute section de texte ajoutée, et les fichiers marqués pour suppression sont affichés comme toute section de texte supprimée. L'affichage de svn diff est compatible avec le programme patch — et encore davantage avec l'introduction de la commande svn patch dans Subversion 1.7. Les commandes patch lisent et appliquent des correctifs (patches en anglais), c'est-à-dire des fichiers qui décrivent les modifications appliquées à un ou plusieurs fichiers. Ainsi, vous pouvez partager les modifications que vous avez faites sur votre copie de travail avec quelqu'un d'autre sans propager ces modifications, mais seulement en créant un fichier correctif obtenu par la redirection de l'affichage de svn diff.

$ svn diff > fichier-correctif
$

Subversion utilise son propre moteur de calcul de différences, qui produit par défaut des résultats au format diff unifié. Si vous désirez obtenir les différences dans un autre format, spécifiez un programme de comparaison externe en utilisant l'option --diff-cmd et en fournissant les paramètres que vous voulez à l'aide de l'option --extensions (-x). Par exemple, pour obtenir les différences entre votre version locale du fichier et l'original de truc.c au format « contexte » et en ignorant la casse des caractères, vous pouvez lancer la commande suivante :

$ svn diff --diff-cmd /usr/bin/diff -x "-i" truc.c
…
$

Avant de décider comment résoudre un conflit de manière interactive, il est probable que vous vouliez examiner le détail des lignes en conflit. Deux des commandes accessibles via l'invite interactive de gestion des conflits répondent à ce besoin. La première est la commande df (pour diff-full en anglais), qui affiche toutes les modifications locales du fichier ainsi que les zones en conflit :

…
Sélectionner : (p) report, (df) diff complet, (e) édite, (m) fusion,
               (mc) my side of conflict, (tc) their side of conflict,
               (s) voir toutes les options:df
--- .svn/text-base/sandwich.txt.svn-base      mar. 11 déc. 2007, 21:33:57
+++ .svn/tmp/tempfile.32.tmp     mar. 11 déc. 2007, 21:34:33
@@ -1 +1,5 @@
-Achète-moi un sandwich.
+<<<<<<< .mien
+Va chercher un hamburger.
+=======
+Apporte-moi un taco !
+>>>>>>> .r32
…

La première ligne du diff correspond à ce que contenait la copie de travail dans l'ancienne version (la révision BASE), la ligne suivante correspond à vos modifications et la dernière ligne contient les modifications reçues du serveur (la révision HEAD la plupart du temps).

La deuxième commande est similaire à la première mais dc(display conflict en anglais) affiche uniquement les zones en conflits, pas toutes les modifications apportées au fichier. En plus, cette commande utilise un format d'affichage légèrement différent qui permet de comparer facilement le contenu du fichier tel qu'il serait dans les trois états : original et non édité ; avec les modifications locales et les changements provenant du serveur qui génèrent des conflits ignorés ; uniquement les changements provenant du serveur et vos modifications locales qui génèrent des conflits ignorés.

Après avoir pris connaissance des informations fournies par ces commandes, vous être prêt à l'action suivante.

La manière la plus directe de résoudre interactivement un conflit utilise un outil interne de fusion. Cet outil vous demande quoi faire pour chaque modification qui pose problème et permet de fusionner et d'adapter les modifications de manière interactive. Cependant, il existe d'autres manières de faire interactivement— deux outils peuvent fusionner et adapter les modifications à l'aide d'éditeurs externes, les autres vous permettent simplement de choisir une version du fichier parmi celles proposées et de passer à la suite.

Vous avez déjà passé en revue les modifications qui posent problème, il est donc temps de résoudre ces conflits. La première commande qui peut vous aider est « merge » (m), disponible à partir de la version 1.8 de Subversion. Cette commande affiche les zones en conflit et vous permet de choisir parmi différentes options pour chaque zone en conflit :

Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options: m
Merging 'Makefile'.
Conflicting section found during merge:
(1) their version (at line 24)                  |(2) your version (at line 24)
------------------------------------------------+------------------------------------------------
top_builddir = /truc                             |top_builddir = /machin
------------------------------------------------+------------------------------------------------
Select: (1) use their version, (2) use your version,
        (12) their version first, then yours,
        (21) your version first, then theirs,
        (e1) edit their version and use the result,
        (e2) edit your version and use the result,
        (eb) edit both versions and use the result,
        (p) postpone this conflicting section leaving conflict markers,
        (a) abort file merge and return to main menu:

Comme vous le constatez, en utilisant l'outil de fusion interne, vous pouvez naviguer entre les différentes zones en conflit dans le fichier et choisir différentes stratégies de résolution, voire remettre à plus tard la résolution du conflit pour certaines zones.

Cependant, si vous souhaitez utiliser un éditeur externe pour choisir une combinaison de vos modifications locales, vous pouvez utiliser la commande « édite » (e) pour modifier manuellement dans un éditeur de texte (configuré en suivant les instructions données dans la section intitulée « Utilisation d'éditeurs externes ») le fichier avec des marqueurs indiquant les conflits. Après avoir édité le fichier et si vous êtes satisfait de vos changements, vous pouvez indiquer à Subversion que le fichier n'est plus en conflit en utilisant la commande « résolu » (r).

En dehors de quelques puristes d'Unix, l'édition manuelle de ce fichier avec votre éditeur préféré peut sembler quelque peu « bas de gamme » (voir la section intitulée « Résolution des conflits à la main » pour une description détaillée), c'est pourquoi Subversion propose d'utiliser des outils graphiques plus évolués et spécialisés dans la fusion de documents (voir la section intitulée « Outils de fusion externes ») avec la commande « launch » (lancer en français), raccourci l).

Il existe deux autres options qui offrent des compromis. Les commandes respectivement « mien-conflits » (mc) et « leur-conflits » (tc) demandent à Subversion de conserver respectivement vos modifications locales et les modifications en provenance du serveur pour tous les conflits rencontrés. Mais, au contraire de « mien complet » et « autre complet », ces commandes conservent à la fois vos modifications et les modifications en provenance du serveur dans les zones du fichier où il n'est pas détecté de conflit.

Enfin, si vous décidez que vous ne voulez pas fusionner les modifications mais simplement conserver une version du fichier ou une autre, vous pouvez choisir votre version (étiquetée « mine ») en sélectionnant la commande « mine-full » (mf) ou choisir la version du dépôt en sélectionnant la commande « theirs-full » (tf).

Le titre peut laisser penser à un paragraphe sur l'amélioration des relations conjugales, mais il s'agit bien toujours de Subversion, voyez plutôt. Si, lorsque vous effectuez une mise à jour, Subversion soulève un conflit que vous n'êtes pas prêt à résoudre, vous pouvez, fichier par fichier, taper p, pour remettre à plus tard la résolution du conflit. Si, lors de votre mise à jour, vous ne voulez résoudre aucun conflit, vous pouvez passer l'option --non-interactive à svn update et les fichiers en conflit sont automatiquement marqués C.

À partir de Subversion 1.8, un outil interne de fusion vous permet de différer la résolution de conflits pour certains conflits et de résoudre les autres. Ainsi, vous pouvez différer la résolution des conflits zone par zone et non plus uniquement fichier par fichier.

Le C indique un conflit, c'est-à-dire que les changements sur le serveur interfèrent avec les vôtres et vous devez donc choisir manuellement entre les différentes modifications après la fin de la procédure de mise à jour. Quand vous repoussez à plus tard la résolution d'un conflit, Subversion accomplit trois actions qui vous aideront à repérer et à résoudre ce conflit :

Par exemple, Sally effectue un changement sur le fichier sandwich.txt mais elle ne propage pas immédiatement ses modifications. Pendant ce temps, Harry propage des changements sur ce même fichier. Sally met à jour sa copie de travail avant d'effectuer la propagation et un conflit apparaît, dont elle remet la résolution à plus tard :

$ svn update
Mise à jour de '.' :
Conflit découvert dans 'sandwich.txt'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options: p
C  sandwich.txt
Actualisé à la révision 2.
Résumé des conflits :
  Text conflicts: 1
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

À partir de là, Subversion n'autorise pas Sally à propager le fichier sandwich.txt avant que les trois fichiers temporaires ne soient effacés :

$ svn commit -m "Quelques petits ajouts"
svn: Échec de la propagation (commit), détails :
svn: Arrêt de la propagation : '/home/sally/travail-svn/sandwich.txt'
                               demeure en conflit

Si vous avez remis à plus tard la résolution d'un conflit, vous devez le résoudre pour que Subversion vous autorise à propager vos changements. Vous pouvez le faire avec la commande svn resolve. Cette commande possède l'option --accept afin de spécifier votre manière de résoudre le conflit. Avant Subversion 1.8, la commande svn resolve exigeait de spécifier l'option. Dorénavant, Subversion vous autorise à ne pas la spécifier. Dans ce cas, Subversion passe en mode de résolution interactif tel que présenté dans la section précédente (voir la section intitulée « Résolution des conflits en mode interactif »). Dans cette section, nous allons présenter l'utilisation de l'option --accept pour la résolution de conflits.

L'option --accept de la commande svn resolve demande à Subversion d'utiliser une des approches prédéfinies pour résoudre un conflit. Si vous choisissez la version du fichier que vous avez extraite avant de faire vos changements, utilisez l'argument --accept=base. Si vous préférez garder la version qui contient uniquement vos changements, utilisez l'argument --accept=mine-full. Vous pouvez aussi choisir la version la plus récente venant du serveur (et donc abandonner tous vos changements) en utilisant l'argument --accept=theirs-full. Il existe d'autres méthodes de résolution « pré-emballées ». Lisez --accept ACTION dans Guide de référence de svn : le client texte interactif pour en obtenir les détails.

Vous n'êtes pas limité à ces choix tout ou rien. Si vous comptez effectuer un mélange de vos modifications et des modifications rapatriées du serveur, fusionnez le fichier en conflit « à la main » (examinez et éditez les marqueurs de conflit dans le fichier) puis indiquez à Subversion de résoudre le conflit en gardant la version de travail dans son état actuel par la commande svn resolve avec l'argument --accept=working.

La commande svn resolve supprime les trois fichiers temporaires et retient la version du fichier que vous avez spécifié avec l'option --accept. À la fin d'exécution de la commande (en considérant bien évidemment que vous n'avez décidé de reporter la résolution du conflit), Subversion considère que le fichier n'est plus dans un état de conflit :

$ svn resolve --accept working sandwich.txt
Conflit sur 'sandwich.txt' résolu

Résoudre les conflits à la main peut paraître quelque peu intimidant la première fois. Mais avec un peu de pratique, un enfant de cinq ans y arriverait.

Prenons un exemple. Par manque de communication entre Sally (votre collaboratrice) et vous-même, vous éditez en même temps le fichier sandwich.txt. Sally propage ses changements et, quand vous mettez à jour votre copie de travail, un conflit apparaît, que vous devez résoudre en éditant sandwich.txt. Jetons un œil à ce fichier :

$ cat sandwich.txt
Tranche de pain supérieure
Mayonnaise
Laitue
Tomate
Comté
<<<<<<< .mine
Saucisson
Mortadelle
Jambon
=======
Choucroute
Poulet rôti
>>>>>>> .r2
Moutarde
Tranche de pain inférieure

Les suites de caractères inférieur-à (<), égal(=) ou supérieur-à (>) sont des marqueurs de conflit, ils ne font pas partie des données elles-mêmes. Vous devrez en général vous assurer qu'elles ont disparu du fichier avant de propager vos modifications. Le texte entre les deux premiers marqueurs est constitué des modifications que vous avez apportées dans la zone de conflit :

<<<<<<< .mine
Saucisson
Mortadelle
Jambon
=======

Le texte entre le deuxième et le troisième marqueur est celui du fichier propagé par Sally :

=======
Choucroute
Poulet rôti
>>>>>>> .r2

Normalement, vous n'allez pas juste supprimer les marqueurs et les changements effectués par Sally (elle sera affreusement déçue quand on lui apportera un sandwich différent de ce qu'elle a commandé). Vous décrochez donc le téléphone, ou vous traversez le bureau, pour expliquer à Sally qu'on ne met pas de choucroute dans un sandwich. ^[7] Après vous être mis d'accord sur les changements à enregistrer, éditez votre fichier et enlevez les marqueurs de conflit.

Tranche de pain supérieure
Mayonnaise
Laitue
Tomate
Comté
Saucisson
Mortadelle
Jambon
Moutarde
Tranche de pain inférieure

Maintenant utilisez svn resolve et vous êtes paré pour propager vos changements :

$ svn resolve --accept working sandwich.txt
Conflit sur 'sandwich.txt' résolu
$ svn commit -m "Va pour mon sandwich et au diable celui de Sally !"

Soyez prudent et ne lancez svn resolve qu'une fois certain que vous avez résolu le conflit dans votre fichier : une fois les fichiers temporaires effacés, Subversion vous laisse propager le fichier même s'il contient toujours des marqueurs de conflit.

Si jamais vous êtes perdu lors de l'édition du fichier en conflit, vous pouvez toujours consulter les trois fichiers que Subversion a créé pour vous dans votre copie de travail, y compris le fichier tel qu'il était avant que vous ne lanciez la mise à jour. Vous pouvez même utiliser un outil externe interactif spécialisé dans les fusions pour examiner ces trois fichiers.

Si vous faites face à un conflit et que vous décidez d'abandonner vos changements, vous pouvez lancer svn resolve --accept theirs-full CHEMIN-DU-CONFLIT, Subversion abandonne alors vos modifications et supprime les fichiers temporaires :

$ svn update
Conflit découvert dans 'machin.c'.
Sélectionner : (p) report, (df) diff complet, (e) édite,
        (h) aide pour plus d'options :
C    sandwich.txt
Actualisé à la révision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ svn resolve --accept theirs-full sandwich.txt
Conflit sur 'sandwich.txt' résolu
$

Si vous faites face à un conflit et qu'après examen de la situation, vous décidez d'abandonner vos changements et de repartir de zéro (peu importe en fait que ce soit après un conflit ou à n'importe quel autre moment), contentez-vous de revenir en arrière sur vos changements :

$ svn revert sandwich.txt
'sandwich.txt' réinitialisé
$ ls sandwich.*
sandwich.txt

Notez que quand vous revenez en arrière sur un fichier en conflit, vous n'avez pas besoin de lancer svn resolve.