Il est probable que vous utiliserez la commande svn status plus que n'importe quelle autre commande Subversion.

Si vous exécutez svn status à la racine de votre copie de travail sans aucun argument, cela détectera tous les changements que vous avez réalisés sur les fichiers et sur l'arborescence. Ci-dessous quelques exemples des différents codes de status que svn status peut renvoyer. (Notez que le texte situé après # n'est pas réellement affiché par la commande svn status.)

  L     some_dir            # svn a laissé un verrou dans le répertoire .svn de some_dir
M       bar.c               # le contenu de bar.c a été modifié localement
 M      baz.c               # baz.c a été modifié au niveau des propriétés mais pas de son contenu
X       3rd_party           # dir fait partie d'une définition externe
?       foo.o               # svn ne gère pas foo.o
!       some_dir            # svn gère cet élément, mais ce dernier est manquant ou incomplet
~       qux                 # versionné en tant que fichier/répertoire/lien, mais le type a changé
I       .screenrc           # svn ne gère pas cet élément, et il lui a été demandé de l'ignorer
A  +    moved_dir           # ajouté avec l'historique hérité de l'original
M  +    moved_dir/README    # ajouté avec un historique hérité et contient des modifications locales
D       stuff/fish.c        # le fichier est marqué pour une suppression
A       stuff/loot/bloo.h   # le fichier est marqué pour être ajouté
C       stuff/loot/lump.c   # fichier sujet à conflit de contenu suite à une mise à jour
 C      stuff/loot/glub.c   # fichier sujet à conflit de propriété suite à une mise à jour
R       xyz.c               # le fichier est destiné à être remplacé
    S   stuff/squawk        # le fichier ou répertoire a été échangé avec une autre branche
     K  dog.jpg             # le fichier est verrouillé localement ; jeton de verrou présent
     O  cat.jpg             # le fichier est verrouilé dans le dépôt par un autre utilisateur
     B  bird.jpg            # le fichier est verrouillé localement, mais le verrou est brisé
     T  fish.jpg            # le fichier est verrouillé localement, mais le verrou a été volé

Dans ce format de sortie svn status affiche cinq colonnes de caractères, suivis de plusieurs caractères d'espacement, suivis par le nom d'un fichier ou d'un répertoire. La première colonne indique le statut d'un fichier ou répertoire et/ou son contenu. Les codes affichés ici sont :

La seconde colonne indique le statut des propriétés d'un fichier ou d'un répertoire (voir the section called “Properties” pour plus d'informations sur les propriétés). Si un M apparaît dans la seconde colonne, alors les propriétés ont été modifiées, sinon un espace sera affiché.

La troisième colonne affichera soit un espace soit un L qui signifie que Subversion a verrouillé la zone de travail .svn du répertoire. Vous verrez L si vous exécutez svn status dans un répertoire où svn commit est en cours — peut-être pendant que vous éditer le commentaire de journal. Si Subversion n'est pas en cours d'exécution, alors vraisemblablement Subversion a été interrompu et le verrou a besoin d'être nettoyé en exécutant svn cleanup (plus de détails plus tard dans ce chapitre).

La quatrième colonne affichera soit un espace soit + qui signifie que le fichier ou répertoire est destiné à être ajouté ou modifié avec un historique hérité en plus du reste. Typiquement, cela arrive lorsque vous utilisez svn move ou svn copy sur un fichier ou un répertoire. Si vous voyez A  +, cela signifie que l'élément est destiné à être ajouté avec un historique hérité. L'élément pourrait être un fichier ou la racine d'un répertoire copié. + signifie q'un élément fait partie d'une sous arborescence destinée à être ajoutée avec un historique hérité, i.e. un parent a été copié and it's just coming along for the ride. M  + signifie que l'élément fait partie d'une sous arborescence destinée à être ajoutée avec un historique hérité et il contient des modifications locales. Lorsque vous lancez une propagation, le parent sera d'abord ajouté avec un historique hérité (copié), ce qui signifie que ce fichier existera automatiquement dans la copie. Puis les modifications locales seront chargées dans la copie.

La cinquième colonne affichera soit un espace soit un S. Cela signifie que le fichier ou répertoire has been switched from the path of the rest of the working copy (using svn switch) to a branch.

La sixième colonne affiche des informations à propos des verrous, sujet dont on parlera plus longuement dans the section called “Locking”.

Si vous passez en paramètre un chemin spécifique à svn status, vous obtiendrez des informations sur ce chemin seulement :

$ svn status stuff/fish.c
D      stuff/fish.c

svn status offre aussi la possibilité d'utiliser l'option --verbose (-v), qui affichera le statut de tous les éléments dans votre copie de travail, même ceux n'ayant pas été modifiés :

$ svn status --verbose
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

Ceci est la “version longue” de l'affichage de svn status. La première colonne reste inchangée, mais la seconde colonne affiche la révision de travail de l'élément. Les troisième et quatrième colonnes affichent la révision durant laquelle l'élément a été modifié pour la dernière fois et qui l'a modifié.

Aucune de ces invocations de svn status ne contacte le dépôt, elles fonctionnent localement en comparant les métadonnées du répertoire .svn avec la copie de travail. Enfin, il reste l'option --show-updates (-u), qui contacte le dépôt et ajoute des informations à propos des éléments qui ne sont pas à jour :

$ svn status --show-updates --verbose
M      *        44        23    sally     README
M               44        20    harry     bar.c
       *        44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
A                0         ?     ?        stuff/things/bloo.h
Status against revision:   46

Remarquez les deux astérisques : si vous exécutiez svn update à cet instant, vous recevriez des modifications pour README et trout.c. Vous avez ainsi obtenu une information très utile — vous devrez mettre à jour votre copie de README avant de pouvoir propager vos modifications sur cet élément, sinon le dépôt rejettera votre propagation du fait que votre copie n'est pas à jour. (ce sujet sera approfondi ultérieurement.)

La commande svn diff est un autre moyen d'examiner vos modifications. Vous pouvez retrouver en détails comment vous avez modifié vos éléments en exécutant svn diff sans aucun argument, ce qui affichera les modifications de vos fichiers au format “unified diff” :^[11]

$ svn diff
Index: bar.c
===================================================================
--- bar.c	(revision 3)
+++ bar.c	(working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

 int main(void) {
-  printf("Sixty-four slices of American Cheese...\n");
+  printf("Sixty-five slices of American Cheese...\n");
 return 0;
 }

Index: README
===================================================================
--- README	(revision 3)
+++ README	(working copy)
@@ -193,3 +193,4 @@ 
+Note to self:  pick up laundry.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c	(revision 1)
+++ stuff/fish.c	(working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h	(revision 8)
+++ stuff/things/bloo.h	(working copy)
+Here is a new file to describe
+things about bloo.

La commande svn diff produit ces informations en comparant les fichiers de votre copie de travail avec les “copies originales” mises en cache dans les répertoires .svn. Les fichiers destinés à être ajoutés sont affichés dans leur intégralité et les fichiers destinés à être effacés sont affichés comme si leur contenu avait complètement été supprimé.

Les différences sont affichées dans le format “ unified diff”. Avec ce format, les lignes effacées sont précédées d'un - et les lignes ajoutées sont précédées avec un +. svn diff affiche aussi le nom du fichier and offset information utiles à la commande patch, ainsi vous pouvez créer des “patches” en redirigeant les données de différence vers un fichier :

$ svn diff > patchfile

Vous pourriez, par exemple, envoyer par courrier électronique le fichier de patch à un autre développeur pour que celui-ci soit vérifié ou testé avant que vos modifications ne soient propagées.

À présent, supposez qu'en examinant les différences ci-dessus, vous réalisiez que vos modifications dans README sont une erreur ; vous avez peut-être accidentellement saisi ce texte dans le mauvais fichier avec votre éditeur.

C'est exactement pour cette situation qu'existe svn revert.

$ svn revert README
Reverted 'README'

Subversion ramène le fichier à son état avant modification en l'écrasant avec la “copie originale” mise en cache dans le répertoire .svn. Mais sachez aussi que svn revert peut annuler toute opération planifiée — par exemple, vous pouvez décider que, finalement, vous ne voulez pas ajouter un nouveau fichier :

$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Reverted 'foo'

$ svn status foo
?      foo

Ou peut-être avez-vous supprimé par erreur un fichier soumis au contrôle de version :

$ svn status README 
       README

$ svn delete README 
D         README

$ svn revert README
Reverted 'README'

$ svn status README
       README

Fusionner les conflits à la main peut être assez intimidant la première fois que vous essaierez, mais avec un peu de pratique, cela peut devenir aussi facile que tomber de vélo.

Voici un exemple. À cause d'un manque de communication, vous et Sally, votre collaboratrice, modifiez tous les deux le fichier sandwich.txt en même temps. Sally applique ses changements, et quand vous voulez mettre à jour votre copie de travail, vous obtenez un conflit et nous allons devoir éditer sandwich.txt pour résoudre les conflits. Tout d'abord, regardons le fichier :

$ cat sandwich.txt
Morceau de pain
Mayonnaise
Laitue
Tomate
Provolone
<<<<<<< .mine
Salami
Mortadelle
Jambon de Prosciutto
=======
Choucroute
Poulet grillé
>>>>>>> .r2
Moutarde Creole
Morceau de paim

La suite de signes inférieurs, égals et supérieurs sont les marqueurs de conflit, et ne font pas partie des données en conflits. Vous voulez généralement vous assurer que ceux-ci sont supprimés du fichier avant votre prochaine soumission. Le texte entre les deux premier ensembles de marqueurs contient les changements que vous avez fait dans la zone de conflit :

<<<<<<< .mine
Salami
Mortadelle
Jambon de Prosciutto
=======

Le texte entre le deuxième et le troisième ensemble de marqueurs vient des modifications de Sally :

=======
Choucroute
Poulet grillé
>>>>>>> .r2

Habituellement, vous ne voudrez pas juste effacer les marqueurs de conflit et les changements de Sally — elle va être affreusement surprise quand le sandwich arrivera et ne sera pas ce qu'elle voulait. Donc c'est le moment où vous décrochez le téléphone ou traversez le bureau et expliquez à Sally que vous ne pouvez pas avoir de choucroute dans un sandwich italien.^[13] Une fois que vous vous êtes mis d'accord sur les changements à apporter, modifiez votre fichier et effacez les marqueurs de conflit.

Morceau de pain
Mayonnaise
Laitue
Tomate
Provolone
Salami
Mortadelle
Jambon Prosciutto
Moutarde Creole
Morceau de pain

Maintenant, lancez svn resolved, et vous êtes prêt à propager vos changements :

$ svn resolved sandwich.txt
$ svn commit -m "Allez-y et utilisez mon sandwich, en annulant les modifications de Sally."

Souvenez-vous, si vous êtes perdu pendant l'édition du fichier conflictuel, vous pouvez toujours consulter les trois fichiers créés par Subversion dans votre copie de travail — y compris votre fichier tel qu'il était avant la mise à jour. Vous pouvez même utiliser un outil tiers de fusion interactive pour examiner ces fichiers.

Si vous avez un conflit et que vous décidez d'annuler vos modifications, vous pouvez seulement remplacer votre copie de travail par un des fichiers temporaires créés par Subversion :

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ cp sandwich.txt.r2 sandwich.txt
$ svn resolved sandwich.txt

Si vous avez un conflit, et après examen decidez que vous voulez oublier vos changements et recommencer votre édition, annulez simplement vos modifications :

$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt

Notez que lorsque vous annulez (revert) un fichier conflictuel, vous n'avez pas besoin de lancer svn resolved.