TortoiseSVN fonctionne sous Windows Vista ou ultérieur et est disponible aussi bien en 32-bit qu'en 64-bit. Le programme d'installation pour la version 64-bit de Windows comprend également les extensions 32-bit. Cela veut dire que vous n'avez pas besoin d'installer la version 32-bit en plus pour avoir le menu contextuel de TortoiseSVN et les icônes superposées dans les applications 32-bit.

Le support pour Windows 98, Windows ME et Windows NT4 a été arrêté à la version 1.2.0, le support pour Windows 2000 et XP jusqu'au SP2 a été arrêté à la version 1.7.0. Le support pour Windows XP SP3 a été arrêté à la version 1.9.0. Vous pouvez encore téléchargé et installer des versions ultérieures au besoin.

TortoiseSVN est livré avec un programme d'installation facile à utiliser. Double cliquez sur le fichier d'installation et suivez les indications. Le programme d'installation s'occupera du reste. N'oubliez pas de redémarrer après l'installation.

Les packs de langue sont disponibles pour traduire l'interface utilisateur de TortoiseSVN dans plusieurs langues. Veuillez vérifier Annexe G, Paquetages linguistiques et correcteurs orthographiques pour davantage d'information sur la procédure d'installation des packs.

Si vous rencontrez des problèmes pendant ou après l'installation de TortoiseSVN, veuillez vous référer à notre FAQ en ligne à l'adresse https://tortoisesvn.net/faq.html.

Pour un projet réel, vous utiliserez un dépôt mis en place dans un endroit sûr et un serveur Subversion pour le contrôler. Dans ce tutoriel, nous allons utiliser les fonctionnalités du dépôt local de Subversion qui permet un accès direct à un dépôt créé sur votre disque dur sans avoir besoin d'un serveur.

Tout d'abord, créez un nouveau dossier vide sur votre PC. Il peut être placé n'importe où, mais dans ce tutoriel, nous appelons l'appeler C:\svn_repos. Faites maintenant un clic droit sur le dossier et choisir dans le menu contextuel TortoiseSVN → Créer un dépôt ici.... Le dépôt est alors créé à l'intérieur du dossier, prêt à l'usage. Nous allons aussi créer la structure interne par défaut du dossier en cliquant sur le bouton Créer la structure du dossier.

Nous avons à présent un référentiel, mais il est complètement vide pour le moment. Supposons que j'aie un ensemble de fichiers dans C:\Projets\Widget1 que je voudrais ajouter. Accédez au répertoire Widget1 dans l'explorateur et faites un clic droit dessus. Maintenant, sélectionnez TortoiseSVN → Importer... qui ouvre une boîte de dialogue.

Figure 1.2. La boîte de dialogue Importer

Un dépôt Subversion est référencé par une URL, ce qui permet de le spécifier de manière univoque partout sur Internet. Dans notre exemple, nous avons besoin de pointer sur notre propre dépôt local qui a une URL du type file:///c:/svn_repos/trunk, auquel nous allons ajouter notre nom de projet Widget1. Notez qu'il y a 3 barres obliques après file: et que ce sont des barres obliques (et non inverses) qui sont utilisées ensuite.

L'autre caractéristique importante de cette boîte de dialogue est la partie Commentaire de l'import qui vous permet d'écrire un message décrivant ce que vous faites. Quand vous regardez votre historique de projet, ces commentaires de livraison sont un guide précieux pour savoir quelles modifications ont été faites et pourquoi. Dans notre exemple, on peut écrire quelque chose de simple comme « Importation du projet Widget1  ». Cliquez sur OK et le dossier est ajouté à votre dépôt.

Maintenant que nous disposons d'un projet dans notre dépôt, nous devons créer une copie de travail à utiliser pour le travail quotidien. Notez que l'action d'importer un dossier ne le convertit pas automatiquement en une copie de travail. Le terme propre à Subversion pour créer une nouvelle copie de travail est Extraire. Nous allons faire une extraction du dossier Widget1 de notre dépôt dans un dossier de développement sur le PC appelé C:\Projects\Widget1-Dev. Créez ce dossier, puis faites un clic droit dessus et choisissez TortoiseSVN → Extraire.... Entrez ensuite l'URL sur laquelle faire l'extraction, dans notre cas file:///c:/svn_repos/trunk/Widget1 et cliquez sur OK. Notre dossier de développement est alors rempli avec les fichiers du dépôt.

Vous remarquerez que l'apparence de ce dossier est différente de celle de notre dossier d'origine. Chaque fichier a une coche verte dans le coin en bas à gauche. Ce sont des icônes d'état TortoiseSVN qui ne sont présentes que dans une copie de travail. L'état vert indique que le fichier est inchangé par rapport à la version dans le dépôt.

Il est temps de se mettre au travail. Dans le répertoire Widget1-Dev, nous commençons à éditer les fichiers — disons que nous apportons des modifications à Widget1.c et ReadMe.txt. Notez que les icônes superposées sur ces fichiers sont passées au rouge, ce qui indique que des modifications ont été apportées en local.

Mais quels sont les changements ? Faites un clic droit sur l'un des fichiers modifiés et sélectionnez TortoiseSVN → Voir les différences. L'outil de comparaison de fichier de TortoiseSVN démarre, vous montrant exactement quelles lignes ont été modifiées.

Figure 1.3. Visualiseur de différences

OK, nous sommes satisfaits des changements, mettons à jour le dépôt. Cette action est appelée Livrer des modifications. Faites un clic droit sur le dossier Widget1-dev et sélectionnez TortoiseSVN → Livrer. La boîte de dialogue de livraison répertorie les fichiers modifiés, chacun avec une case à cocher. Vous pouvez choisir un sous-ensemble de ces fichiers, mais dans ce cas nous allons livrer les modifications apportées aux deux fichiers. Entrez un message pour décrire en quoi consiste le changement et cliquez sur OK. La boîte de dialogue de progression affiche les fichiers en cours de téléchargement dans le dépôt et vous avez terminé.

Avec le développement du projet, vous aurez besoin d'ajouter de nouveaux fichiers - disons que vous ajoutez de nouvelles fonctionnalités dans Extras.c et une référence dans Makefile. Faites un clic droit sur le dossier et TortoiseSVN → Ajouter. La boîte de dialogue Ajouter vous montre maintenant tous les fichiers non versionnés et vous pouvez choisir lesquels vous voulez ajouter. Une autre façon d'ajouter des fichiers serait de faire un clic droit sur le fichier lui-même et de sélectionner TortoiseSVN → Ajouter.

Maintenant, quand vous allez livrer le dossier, le nouveau fichier apparaît comme Ajouté et le fichier existant comme Modifié. Notez que vous pouvez double-cliquer sur le fichier modifié pour vérifier exactement quels changements ont été effectués.

L'une des fonctionnalités les plus utiles de TortoiseSVN est la boîte de dialogue de journal. Celle-ci vous affiche la liste de toutes les modifications que vous avez livrées sur un fichier ou un dossier, et montre les messages de changement détaillés que vous avez entrés (vous avez bien entré un message de changement comme suggéré ? Si non, vous voyez maintenant pourquoi c'est important).

Figure 1.4. La boîte de dialogue de journal

OK, j'ai triché un peu ici, j'ai utilisé une capture d'écran à partir du référentiel TortoiseSVN.

Le panneau supérieur montre une liste des révisions livrées, avec le début du message de livraison. Si vous sélectionnez une de ces révisions, le volet du milieu affiche le message de log complet pour cette révision et le panneau du bas affiche une liste des fichiers et des dossiers modifiés.

Chacun de ces panneaux possède un menu contextuel qui vous donne plusieurs autres moyens d'utiliser les informations. Dans le volet inférieur, vous pouvez double-cliquer sur un fichier pour voir exactement quels changements ont été faits dans cette révision. Lisez la section intitulée « La boîte de dialogue de journal de révision » pour avoir tout le descriptif.

Une caractéristique de tous les systèmes de contrôle de révision, c'est qu'ils vous permettent d'annuler les modifications que vous avez faites précédemment. Comme on peut s'y attendre, TortoiseSVN facilite cette action.

Si vous voulez annuler les changements que vous n'avez pas encore livrés et reprendre la version précédant vos modifications, le menu TortoiseSVN → Revenir en arrière est votre ami. Cela annule vos modifications (en les mettant dans la corbeille, au cas où) et revient à la version livrée avec laquelle vous avez commencé. Si vous voulez annuler seulement quelques-uns des changements, vous pouvez utiliser TortoiseMerge pour voir les différences et annuler, de manière sélective, les lignes modifiées.

Si vous souhaitez annuler les effets d'une révision particulière, lancez la boîte de dialogue de journal et trouvez la révision en question. Sélectionnez menu contextuel → Annuler les changements de cette révision et ces modifications seront annulées.

Considérons ce scénario : supposons que nous avons deux collaborateurs, Harry et Sally. Ils décident chacun d'éditer le même fichier du dépôt en même temps. Si Harry sauvegarde ses changements sur le dépôt en premier, il est possible qu'ensuite (quelques moments plus tard) Sally puisse accidentellement les écraser avec sa propre nouvelle version du fichier. Même si la version d'Harry du fichier ne sera pas perdue pour toujours (parce que le système se rappelle de chaque changement), les changements qu'Harry a fait ne seront pas dans la version plus récente du fichier de Sally, parce qu'elle n'a jamais vu les changements d'Harry en premier lieu. Le travail d'Harry est quand même de facto perdu — ou du moins absent de la dernière version du fichier — et probablement par accident. C'est clairement une situation que nous voulons éviter !

Figure 2.2. Le problème à éviter

Beaucoup de systèmes de contrôle de version utilisent le modèle verrouiller-modifier-déverrouiller pour aborder ce problème, qui est une solution très simple. Dans un tel système, le dépôt ne permet qu'à une seule personne à la foid de modifier un fichier. Tout d'abord, Harry doit verrouiller le fichier avant qu'il ne puisse commencer à y faire des changements. Le verrouillage d'un fichier s'apparente à l'emprunt d'un livre dans une bibliothèque ; si Harry a verrouillé un fichier, alors Sally ne peut pas le modifier. Si elle essaye de verrouiller le fichier, le dépôt refusera la requête. Tout qu'elle peut faire est lire le fichier et attendre qu'Harry finisse ses changements et relâche le verrou. Dès qu'Harry déverrouille le fichier, son tour est fini, et Sally peut alors à son tour le verrouiller et y apporter ses modifications.

Figure 2.3. La solution Verrouiller-Modifier-Déverrouiller

Le problème avec le modèle "verrouiller-modifier-déverrouiller" est qu'il est un peu restrictif et devient souvent un barrage pour les utilisateurs :

Subversion, CVS et les autres systèmes de contrôle de version utilisent un modèle copier-modifier-fusionner comme une alternative au verrouillage. Dans ce modèle, le client de chaque utilisateur lit le dépôt et crée une copie de travail personnelle du fichier ou du projet. Les utilisateurs travaillent alors en parallèle, modifiant leurs copies privées. Finalement, les copies privées sont fusionnées ensemble dans une version nouvelle, finale. Le système de contrôle de version aide souvent avec la fusion, mais en fin de compte un être humain est responsable pour qu'elle se produise correctement.

Voici un exemple. Disons qu'Harry et Sally ont chacun une copie de travail du même projet, extrait du dépôt. Ils travaillent en même temps et modifient localement le même fichier A. Sally sauvegarde ses changements dans le dépôt d'abord. Quand Harry essaie de sauvegarder ses changements, le dépôt l'informe que son fichier A est périmé. Autrement dit, dans le dépôt, ce fichier A a été modifié depuis qu'il a été extrait. Donc Harry demande à son client de fusionner les nouveaux changements du fichier A du dépôt avec sa copie de travail. Il y a des chances que les changements de Sally ne se chevauchent pas avec les siens ; ainsi une fois qu'il a les deux changements intégrés, il sauvegarde sa copie de travail sur le dépôt.

Figure 2.4. La solution Copier-Modifier-Fusionner

Figure 2.5. ...Suite du modèle Copier-Modifier-Fusionner

Mais que se passe-t-il si les changements de Sally chevauchent les changements d'Harry ? Que se passe-t-il alors ? Cette situation est appelée un conflit et habituellement, ce n'est pas vraiment un problème. Quand Harry demande à son client de fusionner les derniers changements du dépôt vers sa copie de travail, sa copie du fichier A est marquée d'une façon ou d'une autre comme étant dans un état de conflit : il sera capable de voir les deux jeux de changements en conflit et choisira manuellement entre eux. Notez que le logiciel ne peut pas résoudre automatiquement les conflits ; seuls les êtres humains sont capables de comprendre et de faire les choix intelligents nécessaires. Une fois qu'Harry a manuellement résolu les changements se chevauchant (peut-être en discutant du conflit avec Sally !), il peut sans risque sauvegarder le fichier fusionné sur le dépôt.

Le modèle copier-modifier-fusionner peut sembler un peu chaotique, mais en pratique, il fonctionne de manière extrêmement fluide. Les utilisateurs peuvent travailler en parallèle, n'ayant jamais à s'attendre. Quand ils travaillent sur les mêmes fichiers, il s'avère que la plupart de leurs changements simultanés ne se chevauchent pas du tout ; les conflits sont peu fréquents. Et le temps que cela prend pour résoudre des conflits est moindre que le temps perdu par un système de verrouillage.

À la fin, tout cela se réduit à un facteur critique : la communication entre les utilisateurs. Quand les utilisateurs communiquent mal, les conflits tant syntaxiques que sémantiques augmentent. Aucun système ne peut forcer les utilisateurs à communiquer parfaitement et aucun système ne peut détecter les conflits sémantiques. Ainsi il n'y a aucune raison d'être apaisé par une fausse promesse qu'un système de verrouillage empêchera d'une façon ou d'une autre des conflits ; en pratique, le verrouillage semble inhiber la productivité plus qu'autre chose.

Il y a une situation commune où le modèle verrouiller-modifier-déverrouiller s'en sort mieux et c'est quand vous avez des fichiers qui ne sont pas fusionnables. Par exemple, si votre dépôt contient quelques images graphiques et deux personnes modifient une image en même temps, il n'y a aucun moyen de fusionner ces changements. Soit Harry, soit Sally perdra ses changements.

Subversion utilise la solution copier-modifier-fusionner par défaut et dans des nombreux cas c'est tout ce dont vous aurez jamais besoin. Cependant, à partir de la version 1.2, Subversion supporte aussi le verrouillage de fichier, si vous avez des fichiers non-fusionnables, ou si vous êtes simplement forcés à une politique de verrouillage par le management, Subversion fournira encore les fonctionnalités dont vous avez besoin.

Vous avez 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 de la copie de travail. Les fichiers de ce 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 un 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 situé immédiatement sous 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 ayez un dépôt contenant deux projets d'application.

Figure 2.6. 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, il faut extraire une partie de l'arborescence 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 fassiez 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'action de publier vos changements est plus communément appelée 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 ayez 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 ne modifie les copies de travail qu'à 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 tous les 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.

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 :

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

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

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, supposons 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, supposons que vous fassiez un changement sur button.c et que vous livriez ce changement. En admettant qu'aucune autre livraison n'ait eu lieu, 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 sera toujours présent dans button.c. Dans cet exemple, le texte de 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 à jour. 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.

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 dépôt, Subversion peut dire dans lequel des quatre états suivants se trouve un fichier de travail :

Maintenant vous avez un nouveau dépôt situé dans D:\SVN\MonNouveauDépôt.

Pour accéder à votre dépôt local vous avez besoin du chemin vers ce dossier. Souvenez-vous juste que Subversion s'attend à des chemins de dépôts dans la forme file:///C:/SVNDépôt/. Notez l'utilisation de slashs.

Pour avoir accès à un dépôt placé sur une partage réseau vous pouvez utiliser soit le mappage de disque, soit le chemin UNC. Pour les chemins UNC, la forme est file://NomDuServeur/chemin/vers/dépôt/. Notez qu'il y a seulement 2 slashs au début ici.

Avant SVN 1.2, les chemins UNC devaient être donnés dans la forme plus obscure file:///\NomDuServeur/chemin/vers/dépôt Cette forme est toujours supportée, mais n'est pas recommandée.

Bien qu'il soit possible en théorie d'utiliser un dépôt FSFS sur un partage réseau et d'avoir un accès multi-utilisateurs en utilisant le protocole file://, ce n'est certainement pas recommandé. En fait, nous le déconseillons fortement, et ne supportons pas un tel usage pour les raisons suivantes :

Les accès de type file:// sont uniquement prévus pour une utilisation locale et mono-utilisateur, en particulier à des fins de test et de debug. Lorsque vous voulez partager votre dépôt, vous devez vraiment mettre en place un vrai serveur, et c'est loin d'être aussi compliqué qu'il y parait. Lisez la section intitulée « Accéder au dépôt » pour obtenir des conseils sur le choix et l'installation d'un serveur.

Avant que vous n'importiez vos données dans le dépôt, vous devriez d'abord réfléchir à la façon dont vous voulez organiser vos données. Si vous utilisez une des dispositions recommandées, ce sera beaucoup plus facile plus tard.

Il y a quelques manières standard et recommandées d'organiser un dépôt. La plupart des personnes créent un répertoire trunk contenant la « version principale » de développement, un répertoire branches qui contient les copies de travail parallèles et un répertoire tags qui contient les versions stables. Si un dépôt ne contient qu'un seul projet, ces répertoires sont créés à la base du dépôt :

/trunk
/branches
/tags
    

Comme cette structure est la plus couramment utilisée, lorsque vous créez un nouveau dépôt avec TortoiseSVN, il vous proposera aussi de créer la structure de répertoire à votre place.

Si un dépôt contient plusieurs projets, les gens indexent souvent leur disposition par branche :

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc
    

...ou par projet :

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags
    

L'indexation par projet a un sens si les projets ne sont pas étroitement liés et si chacun est extrait individuellement. Pour des projets liés où vous pouvez vouloir extraire tous les projets en une fois, ou où les projets sont tous liés ensemble dans un unique package de distribution, il est souvent mieux d'indexer par branche. De cette façon vous avez seulement un tronc à extraire et les relations entre les sous-projets sont plus facilement visibles.

Si vous adoptez une approche /trunk /tags /branches au niveau supérieur, il n'y a rien qui vous impose de copier le tronc en entier pour chaque branche et chaque étiquette, et d'une certaine façon, c'est cette structure qui offre le plus de flexibilité.

Pour les projets sans rapport vous pouvez préférer utiliser des dépôts séparés. Quand vous livrez des changements, c'est le numéro de révision du dépôt entier qui change, pas le numéro de révision du projet. Avoir 2 projets sans rapport qui partagent un dépôt peut signifier de grands écarts dans les numéros de révision. Les projets Subversion et TortoiseSVN apparaissent à la même adresse hôte, mais sont des dépôts complètement séparés permettant le développement indépendant et aucune confusion sur les numéros de génération.

Bien sûr, vous êtes libre d'ignorer ces dispositions communes. Vous pouvez créer n'importe quelle sorte de variation, ce qui marche le mieux pour vous ou votre équipe. Rappelez-vous que quoi que vous choisissez, ce n'est pas un engagement permanent. Vous pouvez réorganiser votre dépôt à tout moment. Comme les branches et les étiquettes sont des répertoires ordinaires, TortoiseSVN peut les déplacer ou les renommer comme vous le souhaitez.

Passer d'une disposition à une autre ne revient qu'à exécuter une série de mouvements côté serveur ; si vous n'aimez pas la façon dont les choses sont organisées dans le dépôt, jonglez juste avec les répertoires.

Si vous n'avez pas encore créé la structure de base de votre dépôt, vous devriez le faire maintenant. Il y a deux manières de le faire. Si vous souhaitez simplement une structure /trunk /tags /branches, vous pouvez utiliser l'explorateur de dépôt pour créer les trois répertoires (dans trois livraisons différentes). Si vous souhaitez créer une arborescence plus complexe, il sera plus simple de le faire directement sur le disque puis de l'importer dans une seule livraison, comme suit :

Notez que le nom du dossier que vous importez n'apparait pas dans le dépôt, seulement son contenu. Par exemple, créez l'arborescence suivante :

C:\Temp\New\trunk
C:\Temp\New\branches
C:\Temp\New\tags

Importez C:\Temp\New à la racine du dépôt, elle ressemblera alors à ceci :

/trunk
/branches
/tags

Figure 4.1. L'explorateur affichant des icônes superposées

Une des fonctionnalités les plus visibles de TortoiseSVN est la superposition d'icônes qui apparaissent sur les fichiers de votre copie de travail. Cela vous permet de voir au premier coup d'œil quels fichiers ont été modifiés. Référez-vous à la section intitulée « Icônes superposées » pour découvrir que représentent les différentes icônes.

Figure 4.2. Menu contextuel pour un répertoire sous contrôle de version

Toutes les commandes de TortoiseSVN sont invoquées à partir du menu contextuel de l'explorateur Windows. La plupart sont directement visibles quand vous faites un clic droit sur un fichier ou sur un dossier. Les commandes disponibles dépendent de si le fichier ou le dossier ou son dossier parent sont sous contrôle de version ou non. Les commandes du menu TortoiseSVN sont également disponibles dans le menu Fichier de l'explorateur.

Dans certains cas, vous pouvez voir plusieurs entrées TortoiseSVN. Ce n'est pas un bug !

Figure 4.3. Menu Fichier de l'explorateur pour un raccourci dans un répertoire versionné

Cet exemple est pour un raccourci non versionné dans un dossier versionné, et dans le menu de fichier de l'Explorateur il y a trois entrées pour TortoiseSVN. L'une est pour le dossier, une autre pour le raccourci lui-même et la troisième pour l'objet sur lequel pointe le raccourci. Pour vous aider à les distinguer entre elles, les icônes ont un indicateur dans le coin inférieur droit pour montrer si l'entrée de menu est pour un fichier, un dossier, un raccourci ou pour plusieurs éléments sélectionnés.

Figure 4.4. Menu pour un répertoire sous contrôle de version lors d'un glisser-déplacer avec le bouton droit

D'autres commandes sont disponibles par glisser-déposer, quand vous glissez-déposez avec le bouton droit des fichiers ou des dossiers vers un nouvel emplacement à l'intérieur des copies de travail ou quand vous glissez-déposez avec le bouton droit un fichier non versionné ou un dossier dans un répertoire qui est sous contrôle de version.

Quelques opérations communes ont des raccourcis Windows bien connus, mais qui n'apparaissent ni sur les boutons ni dans les menus. Si vous ne savez pas comment faire quelque chose d'évident, comme le rafraîchissement d'une vue, regardez ici.

Si le dépôt auquel vous essayez d'avoir accès est protégé par un mot de passe, une boîte de dialogue d'identification s'affichera.

Figure 4.5. Boîte de dialogue d'authentification

Entrez votre nom d'utilisateur et votre mot de passe. La case à cocher fera que TortoiseSVN stockera les accréditations dans le répertoire de Subversion par défaut : %APPDATA%\Subversion\auth dans trois sous-répertoires :

Si vous voulez effacer le cache d'authentification, vous pouvez le faire à partir de la page Données sauvegardées de la boîte de dialogue de configuration de TortoiseSVN. Le bouton Effacer tout effacera les données d'authentification en cache pour tous les dépôts. Le bouton Effacer..., quant à lui, affichera une boîte de dialogue dans laquelle vous pourrez choisir quelles données d'authentification en cache effacer. Référez-vous à la section intitulée « Configuration des données sauvegardées ».

Certaines personnes préfèrent effacer les données d'authentification quand elles se déconnectent de Windows, ou quand elles éteignent l'ordinateur. La façon de faire cela est d'utiliser un script de déconnexion pour supprimer le répertoire %APPDATA%\Subversion\auth, par exemple

@echo off
rmdir /s /q "%APPDATA%\Subversion\auth"

Vous pouvez trouver une description de la façon d'installer ce genre de scripts à http://www.windows-help-central.com/windows-shutdown-script.html.

Pour plus d'informations sur la façon de configurer votre serveur pour l'authentification et contrôle d'accès, reportez-vous à la section intitulée « Accéder au dépôt » .

Beaucoup de fenêtres de TortoiseSVN ont nombre d'informations à afficher, mais il est souvent plus utile de maximiser leur largeur ou leur hauteur plutôt que de les afficher en plein écran. Pour ce faire, il y a des raccourcis dans le bouton Maximiser. Utilisez le bouton du milieu de la souris pour agrandir la hauteur, et le bouton droit de la souris pour élargir.

Si vous importez des éléments dans un dépôt contenant déjà des projets, alors la structure du dépôt aura déjà été décidée. Si vous importez des éléments dans un nouveau dépôt alors il est temps de penser à la manière de l'organiser. Lisez la section intitulée « Disposition du dépôt » pour avoir des conseils.

Cette section décrit la commande Importer de Subversion, qui a été conçue pour importer la hiérarchie d'un dossier dans le dépôt d'un seul coup. Même si ça fait le boulot, cela a plusieurs défauts :

Pour ces raisons nous vous recommandons de ne pas utiliser du tout la commande Importer, mais plutôt de suivre la méthode en 2 étapes décrite dans la section intitulée « Importer en place », sauf si vous faites la simple étape de création de la structure initiale /trunk /tags /branches dans votre dépôt. Puisque vous êtes là, voici comment l'import basique fonctionne...

Avant que vous n'importiez votre projet dans un dépôt, vous devriez :

Choisissez maintenant le dossier de niveau supérieur de votre structure de répertoire de projet dans l'explorateur Windows et faites un clic droit pour ouvrir le menu contextuel. Choisissez la commande TortoiseSVN → Importer... qui fait s'afficher une boîte de dialogue :

Figure 4.6. La boîte de dialogue Importer

Dans cette boîte de dialogue, vous devez saisir l'URL du dépôt dans lequel vous voulez importer votre projet. Il est très important de comprendre que le répertoire local que vous importez n'apparaît pas lui-même dans le dépôt, mais juste son contenu. Par exemple, si vous avez la structure suivante :

C:\Projects\Widget\source
C:\Projects\Widget\doc
C:\Projects\Widget\images

et que vous importez C:\Projects\Widget dans http://monnomdedomaine.com/svn/trunk, alors vous pourriez être surpris de voir que vos sous-répertoires iront directement sous trunk au lieu d'être dans un sous-répertoire Widget. Vous devez spécifier le sous-répertoire comme faisant partie de l'URL, http://monnomdedomaine.com/svn/trunk/Widget-X. Remarquez que la commande Importer créera automatiquement les sous-répertoires dans le dépôt s'ils n'existent pas.

Le message d'importation est utilisé comme commentaire.

Par défaut, les fichiers et les dossiers qui correspondent au filtre d'exclusion ne sont pas importés. Pour ignorer ce comportement, vous pouvez utiliser la case à cocher Inclure les fichiers ignorés. Référez-vous à la section intitulée « Configuration générale » pour plus d'informations sur la configuration d'un filtre d'exclusion.

Dès que vous appuyez sur OK TortoiseSVN importe dans le dépôt l'arborescence complète des répertoires, fichiers compris. Le projet est maintenant sous contrôle de version dans le dépôt. Veuillez noter que le dossier que vous avez importé n'est PAS sous contrôle de version ! Pour obtenir une copie de travail sous contrôle de version, vous devez faire une extraction de la version que vous venez d'importer. Ou vous renseigner sur la manière d'importer un répertoire déjà en place.

Si vous disposez déjà d'un dépôt, et que vous souhaitez y ajouter une nouvelle arborescence, suivez les étapes suivantes :

Parfois vous avez besoin d'avoir sous contrôle de version un fichier qui contient des données spécifiques aux utilisateurs. Cela signifie que vous avez un fichier que chaque développeur/utilisateur doit adapter à son paramétrage local. Mais versionner un tel fichier est difficile car chaque utilisateur livrerait son propre fichier à chaque fois.

Dans de tels cas nous suggérons d'utiliser des fichiers templates. Vous créez un fichier qui contient toutes les données dont vos développeurs auront besoin, ajoutez ce fichier au contrôle de version et laissez les développeurs extraire ce fichier. Alors, chaque développeur doit faire une copie de ce fichier et la renommer. Après cela, modifier la copie n'est plus un problème.

À titre d'exemple, vous pouvez regarder le script de build de TortoiseSVN. Il appelle un fichier nommé default.build.user qui n'existe pas dans le dépôt. Seul le fichier default.build.user.tmpl existe. default.build.user.tmpl est le fichier modèle, dont chaque développeur doit créer une copie et renommer cette copie en default.build.user. À l'intérieur de ce fichier, nous avons ajouté des commentaires pour que les utilisateurs voient quelles sont les lignes qu'ils doivent éditer et modifier selon leur paramétrage local pour qu'il fonctionne.

Afin de ne pas déranger les utilisateurs, nous avons aussi ajouté le fichier default.build.user à la liste des fichiers ignorés de son répertoire parent, c'est-à-dire que nous avons positionné la propriété Subversion svn:ignore pour inclure ce nom de fichier. De cette façon, il n'apparaîtra pas comme non versionné à chaque livraison.

Vous pouvez choisir la profondeur que vous voulez extraire, ce qui vous permet de spécifier la profondeur de récursion dans les sous-répertoires. Si vous voulez juste une partie d'une grosse arborescence, vous pouvez n'extraire que le répertoire de plus haut niveau, et choisir les sous-répertoires à mettre à jour récursivement.

Pour sélectionner facilement les seuls éléments que vous voulez pour l'extraction et forcer la copie de travail obtenue à ne garder que ces éléments, cliquez sur le bouton Choisir les éléments.... Ceci ouvre une nouvelle boîte de dialogue où vous pouvez cocher tous les éléments dont vous voulez dans votre copie de travail et décocher tous les éléments dont vous ne voulez pas. La copie de travail qui en résulte est alors appelée une extraction éparse . La mise à jour d'une telle copie de travail ne récupérera pas les fichiers et dossiers manquants, mais ne mettra à jour que ceux que vous avez déjà dans votre copie de travail.

Si vous procédez à l'extraction d'une copie de travail éparse (c'est-à-dire en choisissant autre chose que totalement récursive pour la profondeur d'extraction), vous poivez facilement ajouter ou supprimer des sous-répertoires plus tard en utilisant une des méthodes suivantes.

Cette fonctionnalité est très utile lorsque vous ne voulez récupérer qu'une partie d'une grosse arborescence, tout en gardant le côté pratique d'une mise à jour d'un seul élément. Supposez que vous avez une grosse arborescence avec des sous répertoires nommés Projet01 à Projet99, et que vous ne vouliez récupérer que Projet03, Projet25 et Projet76/SousProj. Suivez ces étapes :

Si votre copie de travail est à jour et s'il n'y a aucun conflit, vous êtes prêt à livrer vos changements. Choisissez n'importe quel fichier et/ou dossier que vous voulez livrer, puis TortoiseSVN → Livrer....

Figure 4.8. La boîte de dialogue Livrer

La boîte de dialogue Livrer vous montrera chaque fichier changé, y compris les fichiers ajoutés, supprimés et non versionnés. Si vous ne voulez pas qu'un fichier modifié soit livré, décochez ce fichier. Si vous voulez inclure un fichier non versionné, cochez ce fichier pour l'ajouter à la livraison.

Pour cocher ou décocher rapidement des catégories de fichiers, comme tous les fichiers versionnés, ou tous les fichiers modifiés, cliquez sur le lien correspondant juste au-dessus de la liste affichée des éléments modifiés.

Pour des informations sur les couleurs et les éléments supoerposés en fonction de leur statut, veuillez consulter la section intitulée « Statut local et distant ».

Les éléments qui ont été commutés vers un chemin de dépôt différent sont aussi indiqués en utilisant un marqueur (s). Vous pouvez avoir commuté quelque chose en travaillant sur une branche et avoir oublié de rebasculer sur le tronc. C'est votre signal d'alarme !

Double-cliquer sur un fichier modifié dans la boîte de dialogue Livrer lancera l'outil externe de comparaison pour afficher vos changements. Le menu contextuel vous donnera plus d'options, comme affiché sur la capture d'écran. Vous pouvez aussi faire glisser les fichiers vers une autre application comme un éditeur de texte ou un IDE à partir d'ici.

Vous pouvez sélectionner ou désélectionner des éléments en cliquant sur la case à cocher située à leur gauche. Pour les répertoires, vous pouvez utiliser Maj-sélectionner pour le faire récursivement.

Les colonnes affichées dans le panneau du bas sont personnalisables. Si vous faites un clic droit sur n'importe quel en-tête de colonne, vous verrez un menu contextuel permettant de choisir quelles colonnes afficher. Vous pouvez aussi changer la largeur des colonnes en faisant glisser le bord des en-têtes. Ces personnalisations sont conservées, donc vous verrez les mêmes en-têtes la prochaine fois.

Par défaut, lorsque que vous livrez une version, tous les verrous que vous gardez sur des fichiers sont automatiquement retirés à la fin de la livraison. Si vous souhaitez conserver ces verrous, cochez la case Garder les verrous. L'état par défaut de cette case est récupéré dans le fichier de configuration de Subversion, à la clé no_unlock. Lisez la section intitulée « Configuration générale » pour plus d'informations sur l'édition du fichier de configuration de Subversion.

La boîte de dialogue de livraison supporte la fonctionnalité de liste de changements de Subversion pour vous aider à regrouper les fichiers qui sont en lien les uns avec les autres. Pour en savoir plus sur cette fonctionnalité, voyez la section intitulée « Listes de changements ».

Parfois, vous ne voulez livrer qu'une partie des changements que vous avez apportés à un fichier. Ce genre de situation se produit généralement quand vous travaillez sur quelque chose, mais qu'une correction urgente doit être livrée, et qu'il se trouve que cette correction est dans le même fichier que celui sur lequel vous êtes en train de travailler.

Faites un clic droit sur le fichier et utilisez Menu contextuel → Restauration après la livraison. Cela créera une copie du fichier dans son état actuel. Ensuite vous pouvez éditer le fichier, par exemple dans un éditeur de texte, et annuler tous les changements que vous ne voulez pas livrer maintenant. Après avoir sauvegardé ces changements, vous pouvez livrer le fichier.

Une fois que la livraison est effectuée, la copie du fichier est restaurée automatiquement, et vous avez votre fichier avec toutes les modifications qui n'ont pas été livrées.

Il y a parfois des fichiers versionnés qui sont fréquemment modifiés mais que vous ne voulez vraiment pas livrer à chaque fois. Cela peut parfois indiquer un défaut dans votre processus de génération : pourquoi ces fichiers sont-ils versionnés ? Ne devriez-vous pas utiliser des fichiers templates ? Cependant, c'est parfois inévitable. Un cas typique est quand votre fichier de projet contient la date et l'heure de la dernière compilation. Le fichier de projet doit être versionné dans la mesure où il contient toutes les propriétés de compilation, mais pas nécessairement livré quand seul l'horodatage a changé.

Pour vous aider à gérer ce genre de cas problématiques, nous avons prédéfini une liste de changements appelée ignore-on-commit (« ignorer à la livraison »). Tout fichier ajouté dans cette liste sera automatiquement décoché dans la fenêtre de livraison. Vous pouvez cependant toujours livrer les modifications en cochant manuellement les fichiers à livrer dans la fenêtre de livraison.

Assurez-vous d'entrer un commentaire qui décrit les changements que vous livrez. Cela vous aidera à voir ce qui est arrivé et quand, lorsque vous naviguerez dans les commentaires du projet à une date ultérieure. Le message peut être aussi long ou aussi court que vous le souhaitez ; beaucoup de projets ont des directives pour ce qui devrait être inclus, la langue à utiliser et parfois même un format strict.

Vous pouvez appliquer un formatage simple à vos commentaires en utilisant une convention similaire à celle utilisée dans les e-mails. Pour appliquer un style à un texte, utilisez *texte* pour le gras, _texte_ pour souligner, et ^texte^ pour l'italique.

Figure 4.9. Le vérificateur d'orthographe de la boîte de dialogue Livrer

TortoiseSVN inclut un vérificateur d'orthographe pour vous aider à obtenir des commentaires corrects. Il mettra en évidence les mots mal orthographiés. Utilisez le menu contextuel pour avoir accès aux corrections suggérées. Bien sûr, il ne connaît pas tous les termes techniques comme vous, donc parfois les mots correctement orthographiés s'afficheront en tant qu'erreurs. Mais ne vous inquiétez pas. Vous pouvez simplement les ajouter à votre dictionnaire personnel en utilisant le menu contextuel.

La fenêtre de commentaire comprend aussi une fonctionnalité de complétion automatique de noms de fichier et de fonction. Elle utilise des expressions régulières pour extraire les noms de classe et de fonction des fichiers (texte) que vous livrez, ainsi que les noms de fichiers eux-mêmes. Si un mot que vous tapez correspond à quelque chose dans la liste (une fois que vous avez tapé au moins 3 caractères ou appuyé sur Ctrl+Espace), une liste déroulante apparaît pour vous permettre de sélectionner le nom complet. Les expressions régulières fournies avec TortoiseSVN sont contenues dans le dossier bin de l'installation de TortoiseSVN. Vous pouvez également définir vos propres expressions régulières et les stocker dans %APPDATA%\TortoiseSVN\autolist.txt. Naturellement, votre fichier autolist privé ne sera pas écrasé lors d'une mise à jour de votre installation de TortoiseSVN. Si vous n'êtes pas à l'aise avec les expressions régulières, jetez un œil à l'introduction à https://fr.wikipedia.org/wiki/Expression_r%C3%A9guli%C3%A8re. Vous pouvez également accéder à de la documentation en ligne et un tutoriel en anglais à https://www.regular-expressions.info/.

Écrire l'expression régulière parfaite peut s'avérer complexe. Pour vous aider à la trouver, il y a une boîte de dialogue de test qui vous permet de saisir une expression, puis de taper des noms de fichier pour la tester. Vous pouvez la démarrer depuis l'invite de commandes avec la commande TortoiseProc.exe /command:autotexttest.

La fenêtre de commentaire incorpore également un générateur de messages de livraison type. Ces messages type apparaissent dans la liste déroulante de complétion automatique une fois que vous tapez un raccourci de message type, et on peut ensuite insérer l'intégralité du texte du message type en sélectionnant ce message type dans la liste déroulante de complétion automatique. Les messages type fournis avec TortoiseSVN sont situés dans le dossier bin de l'installation de TortoiseSVN. Vous pouvez aussi définir vos propres messages type et les stocker dans %APPDATA%\TortoiseSVN\snippet.txt. # est la marque de commentaire. On peut insérer un retour à la ligne en l'échappant de cette façon : \n et \r. Pour insérer un antislash, il faut l'échapper de cette façon : \\.

Vous pouvez réutiliser les messages de livraison des livraisons précédentes. Cliquez juste sur Messages récents pour en voir la liste. Le nombre de messages à garder en mémoire peut être modifié dans la fenêtre de propriété de TortoiseSVN.

Vous pouvez supprimer tous les messages de livraison récents depuis la page Données sauvegardées de la fenêtre de configuration de TortoiseSVN. Vous pouvez également supprimer les messages individuellement depuis la boîte de dialogue Messages récents en utillisant la touche Suppr.

Si vous souhaitez inclure les chemins mis à jour dans votre message, vous pouvez utiliser la commande Menu Contextuel → Coller la liste des noms de fichier dans le champ texte.

Une autre façon d'insérer des chemins dans les commentaires est simplement de glisser/déposer les fichiers depuis la liste des fichiers dans le champ d'édition du message.

Après avoir appuyé sur OK, une boîte de dialogue apparaît affichant la progression de la livraison.

Figure 4.10. La boîte de dialogue de progression montrant une livraison en cours

La boîte de dialogue de progression utilise un code de couleurs pour mettre en évidence les diverses actions de la livraison

C'est la combinaison de couleurs par défaut, mais vous pouvez personnaliser ces couleurs en utilisant la boîte de dialogue de configuration. Lisez la section intitulée « Configuration des couleurs de TortoiseSVN » pour plus d'informations.

Un conflit de fichier se produit quand plusieurs développeurs changent les mêmes lignes d'un fichier. Comme Subversion ne connaît rien à votre projet, il laisse aux développeurs le soin de résoudre les conflits. La région en conflit dans un fichier texte est marquée comme ceci :

<<<<<<< nom de fichier
vos changements
=======
code récupéré du dépôt
>>>>>>> révision

De plus, pour chaque fichier en conflit, Subversion positionne trois fichiers supplémentaires dans votre répertoire :

Vous pouvez soit lancer un outil externe de fusion ou un éditeur de conflits avec TortoiseSVN → Editer les conflits, soit utiliser l'éditeur de texte de votre choix pour résoudre le conflit manuellement. C'est à vous de décider à quoi le code doit ressembler, de faire les changements nécessaires et de sauvegarder le fichier. Utiliser un outil de fusion comme TortoiseMerge ou un autre outil populaire est généralement la solution la plus simple, car ils présentent généralement les fichiers concernés dans une vue à 3 colonnes et vous n'avez pas besoin de vous soucier des marqueurs de conflit. Si vous utilisez un éditeur de texte, alors vous devrez chercher les lignes qui commencent par la chaîne de caractères <<<<<<<.

Exécutez ensuite la commande TortoiseSVN → Résolu... et livrez vos modifications au dépôt. Veuillez noter que la commande de résolution ne résout pas vraiment le conflit. Elle supprime juste les fichiers nom_du_fichier.ext.mine et nom_du_fichier.ext.r*, pour vous permettre de livrer vos changements.

Si vous avez des conflits avec des fichiers binaires, Subversion n'essaye pas de fusionner les fichiers lui-même. Le fichier local reste inchangé (exactement comme la dernière fois que vous l'avez modifié) et vous avez des fichiers nom_du_fichier.ext.r*. Si vous voulez renoncer à vos changements et garder la version du dépôt, utilisez simplement la commande Revenir en arrière. Si vous voulez garder votre version et écraser la version du dépôt, utilisez la commande Résolu..., puis livrez votre version.

Vous pouvez utiliser la commande Résolu... pour plusieurs fichiers si vous faites un clic droit sur le dossier parent et sélectionnez TortoiseSVN → Résolu... Cela affichera une boîte de dialogue listant tous les fichiers en conflit dans ce dossier et vous pouvez choisir lesquels marquer comme résolus.

Un conflit de propriété se produit lorsque plusieurs développeurs ont changé la même propriété. Comme avec le contenu des fichiers, la résolution du conflit ne peut être faite que par les développeurs.

Si un des changements doit remplacer l'autre, alors choisissez l'option Résoudre en utilisant la propriété locale ou Résoudre en utilisant la propriété distante. S'il faut fusionner les changements, alors sélectionnez Editer la propriété manuellement, déterminez quelle doit être la valeur de la propriété et marquez comme résolu.

Un conflit dans l'arborescence se produit quand un développeur a déplacé/renommé/supprimé un fichier ou un dossier qu'un autre développeur a soit lui aussi déplacé/renommé/supprimé, soit simplement modifié. Plusieurs situations peuvent générer un conflit d'arborescence, et chacune a une solution différente.

Quand un fichier est marqué pour suppression par la commande Supprimer de Subversion, il est aussi supprimé du système de fichiers local. De ce fait, même s'il génère un conflit d'arborescence, il ne peut pas afficher une icône superposée indiquant son état en conflit, et on ne peut pas faire un clic droit dessus pour résoudre le conflit. Utilisez la boîte de dialogue Vérifier les modifications à la place pour pouvoir accéder à l'option Editer les conflits.

TortoiseSVN peut aider à trouver les endroits où fusionner les modifications, mais cela ne résoudra pas forcément tous les conflits. Souvenez-vous qu'après une mise à jour, la base de travail contiendra la révision de chaque élément tel qu'il était dans le dépôt au moment de la mise à jour. Si vous annulez une modification après avoir fait une mise à jour, l'élément reviendra à la version du dépôt, pas à l'état dans lequel était l'élément avant que vous fassiez vos modifications.

Figure 4.12. L'explorateur affichant des icônes superposées

Maintenant que vous avez extrait une copie de travail à partir d'un dépôt Subversion, vous pouvez voir que vos fichiers ont de nouvelles icônes dans l'explorateur Windows. C'est une des raisons pour lesquelles TortoiseSVN est si populaire. TortoiseSVN ajoute une icône superposée à chaque icône de fichier, par-dessus l'icône de fichier originale. Suivant le statut Subversion du fichier, l'icône superposée est différente.

Une copie de travail fraîchement extraite a une coche verte comme icône superposée. Cela signifie que le statut Subversion est normal.

Dès que vous commencez à éditer un fichier, le statut passe à modifié et l'icône superposée devient alors un point d'exclamation rouge. De cette façon, vous pouvez facilement voir quels fichiers ont été modifiés depuis votre dernière mise à jour de la copie de travail et doivent donc être livrés.

Si un conflit se produit lors d'une mise à jour, alors l'icône superposée devient un point d'exclamation jaune.

Si vous avez mis la propriété svn:needs-lock sur un fichier, Subversion met ce fichier en lecture seule jusqu'à ce que vous verrouilliez ce fichier. Ces fichiers ont cette icône superposée pour indiquer que vous devez d'abord les verrouiller pour pouvoir les éditer.

Si vous avez verrouillé un fichier et que le statut de Subversion est normal, cette icône superposée vous rappelle que vous devriez relâcher le verrou si vous ne l'utilisez pas pour permettre aux autres utilisateurs de livrer leurs changements.

Cette icône vous montre que certains fichiers ou dossiers à l'intérieur du dossier ont été marqués comme à supprimer du contrôle de version, ou qu'un fichier versionné est absent d'un dossier.

Le signe plus vous indique qu'un fichier ou un dossier a été marqué comme à ajouter au contrôle de version.

Le signe « sens interdit » vous indique qu'un fichier ou un dossier a été marqué à ignorer par le contrôle de version. Cette icône superposée est optionnelle.

Cette icône est associée aux éléments qui ne sont pas versionnés, mais qui ne sont pas à ignorer. Cette icône superposée est optionnelle.

En fait, vous allez peut-être constater que ces icônes ne sont pas toutes utilisées sur votre système. C'est dû au fait que le nombre de superpositions permis par Windows est très limité et si vous utilisez aussi une vieille version de TortoiseCVS, alors il n'y a pas assez d'emplacements de superposition disponibles. TortoiseSVN essaie d'être un « Bon Citoyen (TM) » et limite son utilisation des superpositions pour laisser de la place aux autres applications.

Maintenant qu'il y a de plus en plus de clients Tortoise dans les parages (TortoiseCVS, TortoiseHg, ...) la limite du nombre d'icônes devient vraiment problématique. Pour contourner cela, le projet TortoiseSVN a introduit un jeu d'icônes communes partagées, chargé dans une DLL, qui peut être utilisé par tous les clients Tortoise. Vérifiez avec le fournisseur de votre client si cela y a déjà été intégré :-)

Pour avoir une description de la correspondance entre les icônes superposées et les statuts de Subversion ainsi que d'autres détails techniques, lisez la section intitulée « Icônes superposées ».

Figure 4.13. Page de propriétés de l'explorateur, onglet Subversion

Parfois vous voulez avoir des informations sur un fichier/répertoire qui soient plus détaillées que la simple icône superposée. Vous pouvez obtenir toutes les informations que Subversion fournit dans la boîte de dialogue de propriétés de l'explorateur. Sélectionnez simplement le fichier ou le répertoire et choisissez Menu Windows → Propriétés dans le menu contextuel (remarque : c'est l'entrée de menu de propriétés standard que l'explorateur fournit, pas celle du sous-menu TortoiseSVN !). Dans la boîte de dialogue de propriétés, TortoiseSVN a ajouté une nouvelle page de propriétés pour les fichiers/dossiers sous le contrôle de Subversion, où vous verrez toutes les informations pertinentes concernant le fichier/répertoire sélectionné.

Figure 4.14. Vérifier les modifications

Il est souvent très utile de savoir quels fichiers vous avez changés et aussi quels fichiers ont été changés et livrés par les autres. C'est là que la commande TortoiseSVN → Vérifier les modifications... devient pratique. Cette boîte de dialogue vous montrera tous les fichiers qui ont été modifiés dans votre copie de travail, ainsi que tous les fichiers non versionnés que vous pouvez avoir.

Si vous cliquez sur Vérifier le dépôt alors vous pouvez aussi chercher les changements dans le dépôt. De cette manière vous pouvez vérifier avant une mise à jour s'il y a un conflit potentiel. Vous pouvez aussi mettre à jour certains fichiers depuis le dépôt sans mettre à jour le dossier entier. Par défaut, le bouton Vérifier le dépôt ne récupère que le statut du dépôt à la profondeur de la copie de travail. Si vous voulez voir tous les fichiers et répertoires du dépôt, même ceux que vous n'avez pas extraits, vous devez cliquer sur le bouton Vérifier le dépôt en appuyant sur la touche Maj.

La boîte de dialogue utilise un code couleur pour mettre le statut en évidence.

C'est la combinaison de couleurs par défaut, mais vous pouvez personnaliser ces couleurs en utilisant la boîte de dialogue de configuration. Lisez la section intitulée « Configuration des couleurs de TortoiseSVN » pour plus d'informations.

Les icônes superposées sont également utilisées pour indiquer d'autres états. La capture d'écran ci-dessous montre toutes les icônes superposées qui peuvent être affichées si nécessaire.

Des icônes superposées sont affichées pour les états suivants :

Les éléments qui ont été basculés vers un chemin différent dans le dépôt sont également indiquée avec un marqueur (s). Vous avez peut-être basculé quelque chose pendant que vous travailliez sur une branche et vous avez oublié de rebasculer sur le trunk. Ceci est votre signal d'alarme ! Le menu contextuel vous permet de les rebasculer vers le chemin normal.

À partir du menu contextuel de la boîte de dialogue, vous pouvez afficher une comparaison des changements. Vérifiez les changements locaux que vous avez faits en utilisant Menu contextuel → Comparer avec la Base. Vérifiez les changements du dépôt faits par les autres en utilisant Menu contextuel → Voir les différences en mode diff unifié.

Vous pouvez aussi annuler des changements dans des fichiers individuels. Si vous avez supprimé un fichier accidentellement, il apparaîtra comme Manquant et vous pourrez utiliser Revenir en arrière pour le récupérer.

Les fichiers non versionnés et les fichiers ignorés peuvent être envoyés dans la corbeille à partir d'ici en utilisant Menu contextuel → Supprimer. Si vous voulez supprimer définitivement les fichiers (sans passer par la corbeille) maintenez la touche Maj pendant que vous cliquez sur Supprimer.

Si vous voulez examiner un fichier en détail, vous pouvez le faire glisser depuis ici vers une autre application comme un éditeur de texte ou IDE, ou vous pouvez enregistrer une copie en le faisant simplement glisser vers un dossier dans l'explorateur.

Les colonnes affichées sont personnalisables. Si vous faites un clic droit sur n'importe quel en-tête de colonne, un menu contextuel apparaîtra pour vous permettre de choisir les colonnes à afficher. Vous pouvez aussi changer la largeur de colonne en faisant glisser le bord des en-têtes. Ces personnalisations sont préservées, donc vous verrez les mêmes en-têtes la prochaine fois.

Si vous travaillez sur plusieurs tâches distinctes en même temps, vous pouvez regrouper les fichiers dans des listes de modification. Lisez la section intitulée « Listes de changements » pour plus d'informations.

En bas de la boîte de dialogue vous pouvez apercevoir un sommaire de l'éventail des révisions en mémoire utilisées dans votre copie active. Celles-ci sont du type Livrer, et non de type mise à jour; elles représentent l'éventail de révisions où ces fichiers ont été livrés dernièrement, et non les révisions vers lesquelles elles ont été mises à jour. Notez que l'éventail de révisions présentées s'applique uniquement aux éléments affichés, et non à la copie active entière. Si vous désirez voir cette information pour la copie active dans son intégralité vous devez cocher la case Montrer les éléments non-modifiés.

Souvent vous voulez regarder à l'intérieur de vos fichiers, pour examiner ce que vous avez changé. Vous pouvez accomplir cela en sélectionnant un fichier qui a changé et en choisissant Voir les différences à partir du menu contextuel de TortoiseSVN. Cela démarre le visualisateur externe de différences, qui comparera alors le fichier actuel avec la copie primitive (la révision BASE), qui a été stockée après la dernière extraction ou la dernière mise à jour.

Figure 4.18. La boîte de dialogue de journal de révision

Il existe plusieurs endroits à partir desquels vous pouvez afficher la boîte de dialogue de journal :

Si le dépôt n'est pas joignable vous verrez une fenêtre Travailler hors ligne ?, décrite dans la section intitulée « Mode hors ligne ».

Le panneau supérieur a une colonne Actions contenant des icônes qui résument ce qui a été fait dans cette révision. Il y a quatre icônes différentes, chacune est affichée dans sa propre colonne.

Si un fichier ou un répertoire a été modifié dans la révision, l'icône modifié est affichée dans la première colonne.

Si un fichier ou un répertoire a été ajouté dans la révision, l'icône ajouté est affichée dans la deuxième colonne.

Si un fichier ou un répertoire a été supprimé dans la révision, l'icône supprimé s'affiche dans la troisième colonne.

Si un fichier ou un répertoire a été remplacé dans la révision, l'icône remplacé est affichée dans la quatrième colonne.

Si un fichier ou un répertoire a été déplacé ou renommé dans la révision, l'icône déplacé est affichée dans la quatrième colonne.

Si un fichier ou un répertoire a été remplacé dans la révision au moyen d'un déplacement ou d'un renommage, l'icône déplacé remplacé est affichée dans la quatrième colonne.

Si un fichier ou un répertoire a été fusionné dans la révision, l'icône fusionné est affichée dans la quatrième colonne.

Si un fichier ou un répertoire a fait l'objet d'une fusion inversée dans la révision, l'icône fusionné inversé est affichée dans la quatrième colonne.

Figure 4.19. Le panneau supérieur de la boîte de dialogue de journal de révision avec le menu contextuel

Le panneau supérieur de la boîte de dialogue de journal a un menu contextuel qui vous permet d'accéder à beaucoup d'informations supplémentaires. Certains de ces éléments de menu n'apparaissent que quand on affiche le journal d'un fichier, et d'autres que quand on affiche le journal d'un dossier.

Figure 4.20. La boîte de dialogue de paramètres du Collaborateur de Code

Figure 4.21. Menu contextuel du panneau supérieur avec 2 révisions sélectionnées

Si vous sélectionnez deux révisions en même temps (en utilisant le modificateur habituel Ctrl), le menu contextuel change et vous propose moins d'options :

Si vous sélectionnez au moins deux révisions (en utilisant les modificateurs habituels Ctrl ou Shift), le menu contextuel inclura une entrée pour Annuler toutes les modifications qui ont été faites dans ces révisions. C'est la façon la plus facile d'annuler un groupe de révisions en une fois.

Vous pouvez également choisir de fusionner les révisions sélectionnées dans une autre copie de travail, comme décrit ci-dessus.

Si toutes les révisions sélectionnées ont le même auteur, vous pouvez éditer le champ auteur en une seule opération.

Figure 4.22. Le panneau inférieur de la boîte de dialogue de journal avec le menu contextuel

Le panneau inférieur de la boîte de dialogue de journal a aussi un menu contextuel qui vous permet de

Quand plusieurs fichiers sont sélectionnés dans le panneau inférieur de la boîte de dialogue de journal, le menu contextuel devient comme suit :

Figure 4.23. Le panneau inférieur de la boîte de dialogue de journal avec le menu contextuel quand plusieurs fichiers sont sélectionnés.

La boîte de dialogue de journal ne montre pas toujours toutes les modifications faites pour plusieurs raisons :

Si vous voulez voir plus de commentaires de révision, cliquez sur le bouton 100 suivants pour récupérer les 100 commentaires suivants. Vous pouvez répéter cela autant de fois que nécessaire.

À côté de ce bouton il y a un bouton multi-fonctions qui se souvient de la dernière option pour laquelle vous l'avez utilisé. Cliquez sur la flèche pour voir les autres options offertes.

Utilisez Afficher la plage ... si vous voulez consulter une plage spécifique de révisions. Une boîte de dialogue vous demandera alors d'entrer les révisions de début et de fin.

Utilisez Afficher tout si vous voulez voir tous les commentaires depuis HEAD jusqu'à la révision 1.

Pour actualiser la dernière révision dans le cas où d'autres livraisons auraient eu lieu pendant que la boîte de dialogue du journal était ouverte, pressez la touche F5.

Pour actualiser le cache du journal, appuyez sur Ctrl-F5.

La fenêtre de commentaires affichant les commentaires depuis HEAD et non depuis la révision de la copie de travail, il arrive souvent que des commentaires de révisions non encore importées dans votre copie de travail soient affichés. Pour clarifier, le commentaire de livraison correspondant à la révision de votre copie de travail est affiché en gras.

Quand vous affichez le journal pour un répertoire, la révision mise en évidence est la plus élevée trouvée dans ce répertoire, ce qui nécessite un parcours de la copie de travail. Ce parcours est effectué dans un autre thread pour ne pas ralentir l'affichage du journal, mais en conséquence la mise en évidence de la révision pour les répertoires peut ne pas apparaître immédiatement.

Le logiciel Subversion en version 1.5 et ultérieure garde une trace des fusions à l'aide de propriétés. Cela nous permet d'obtenir un historique plus détaillé des changements fusionnés. Par exemple, si vous développez une nouvelle fonctionnalité dans une branche, puis que vous fusionnez cette branche dans le trunk, le développement de la fonctionnalité s'affichera dans le journal du trunk sous la forme d'une livraison unique pour la fusion, alors qu'il a pu y avoir 1000 livraisons pendant le développement dans la branche.

Figure 4.24. La boîte de dialogue de journal montrant les révisions avec suivi de fusion

Si vous voulez voir le détail des révisions qui ont été fusionnées dans cette livraison, utilisez la case à cocher Inclure les révisions fusionnées. Cela récupèrera à nouveau les commentaires de révision, mais en incluant également les commentaires des révisions fusionnées. Les révisions fusionnées sont affichées en gris car elles représentent des modifications effectuées dans une autre branche de l'arborescence.

Bien sûr, fusionner n'est jamais une mince affaire ! Pendant le développement des fonctionnalités dans une branche, il y aura sûrement des fusions à faire avec le trunk pour que la branche reste synchronisée avec la version principale. Donc l'historique des fusions de la branche inclura une autre couche d'historique de fusions. Ces différentes couches sont affichées dans la fenêtre du journal avec une indentation différente.

Les propriétés de révision, ou revprops, sont complètement différentes des propriétés de Subversion de chaque élément. Les revprops sont des éléments descriptifs qui sont associés à un numéro de révision spécifique dans le dépôt, comme les commentaires de révision, date de livraison et nom de la personne ayant livré (auteur).

Parfois vous pourriez vouloir changer un commentaire que vous avez saisi, peut-être parce qu'il y a une faute d'orthographe dedans ou parce que vous voulez améliorer le message ou le changer pour d'autres raisons. Ou vous voulez changer l'auteur de la livraison parce que vous avez oublié de mettre en place l'authentification ou...

Subversion vous permet de changer les propriétés de révision à tout moment. Mais comme ces changements ne peuvent pas être annulés (car ils ne sont pas versionnés) cette fonctionnalité est désactivée par défaut. Pour la faire marcher, vous devez mettre en place un hook pre-revprop-change. Référez-vous au chapitre sur les Scripts hooks dans le livre de Subversion pour des détails sur la façon de faire. Lisez la section intitulée « Scripts hook côté serveur » pour des notes complémentaires sur la façon d'implémenter des hooks sur une machine Windows.

Une fois que vous avez mis en place votre serveur avec les hooks requis, vous pouvez changer l'auteur et le commentaire (ou toute autre revprop) de n'importe quelle révision, en utilisant le menu contextuel du panneau supérieur de la boîte de dialogue de journal. Vous pouvez également éditer un commentaire de révision par l'intermédiaire du menu contextuel du panneau du milieu.

Si vous voulez limiter les commentaires pour afficher seulement ceux qui vous intéressent plutôt que de faire défiler une liste de centaines de commentaires, vous pouvez utiliser les commandes de filtre en haut de la boîte de dialogue de journal. Les dates de début et de fin vous permettent de limiter les résultats à une plage de dates connues. La boîte de recherche vous permet de n'afficher que les messages qui contiennent une expression particulière.

Cliquez sur l'icône de recherche pour sélectionner le type d'information que vous souhaitez rechercher, et pour choisir le mode regex. Vous n'aurez généralement besoin que d'une simple recherche de sous-chaînes, mais si vous souhaitez plus de flexibilité, vous pouvez utiliser les expressions régulières. Si vous passez la souris au dessus de la boîte, une infobulle vous donnera des informations sur la façon d'utiliser les fonctions d'expressions régulières ou les fonctions de sous-chaînes. Le filtre fonctionne en vérifiant si les entrées du journal correspondent à votre chaîne de filtrage, puis seules les entrées qui correspondent à ce filtre sont affichées.

La recherche de sous-chaîne simple fonctionne d'une façon similaire à un moteur de recherche. Les chaînes à rechercher sont séparées par des espaces, et toutes les chaînes doivent avoir une correspondance. Vous pouvez utiliser le préfixe - pour spécifier qu'une sous-chaîne donnée ne doit pas être trouvée (correspondance inversée pour ce terme), et vous pouvez utiliser ! au début d'une expression pour inverser la correspondance pour l'expression entière. Vous pouvez utiliser le préfixe + pour spécifier qu'une sous-chaîne doit être incluse, même si elle a précédemment été exclue par un -. Remarquez que l'ordre des inclusions et exclusions est ici significatif. Vous pouvez utiliser des guillemets autour d'une chaîne qui doit contenir des espaces, et si vous voulez chercher un guillemet dans la chaîne vous pouvez utiliser deux guillemets consécutifs comme séquence d'échappement. Remarquez que le caractère antislash n'est pas utilisé comme séquence d'échappement et n'a pas de signification spéciale dans des recherches de sous-chaînes simples. Des exemples faciliteront la compréhension :

Alice Bob -Eve

recherche des chaînes qui contiennent à la fois Alice et Bob, mais pas Eve.

Alice -Bob +Eve

recherche des chaînes qui soit contiennent Alice et ne contiennent pas Bob, soit contiennent Eve.

-Cas +CasSpécial

recherche des chaînes qui ne contiennent pas Cas, mais inclut quand même les chaînes qui contiennent CasSpécial.

!Alice Bob

recherche des chaînes qui ne contiennent pas à la fois Alice et Bob.

!-Alice -Bob

Vous vous souvenez des lois de De Morgan ? NON(NON Alice ET NON Bob) se réduit en (Alice OU Bob).

"Alice et Bob"

recherche l'expression exacte « Alice et Bob ».

""

recherche un guillemet n'importe où dans le texte.

"Alice dit ""bonjour"" à Bob"

recherche l'expression exacte « Alice dit "bonjour" à Bob ».

Décrire l'utilisation des recherches par expressions régulières dépasse le cadre de ce manuel, mais vous pouvez jeter un coup d'œil à la documentation en ligne et au didacticiel à http://www.regular-expressions.info/.

Notez que ces filtres agissent sur les commentaires déjà récupérés. Ils ne provoquent pas de téléchargement de commentaires du dépôt.

Vous pouvez aussi filtrer les noms de chemin dans le panneau du bas en utilisant la case à cocher Ne montrer que les chemins affectés. Les chemins affectés sont ceux qui contiennent le chemin utilisé pour montrer le journal. Si vous parcourez le journal pour un dossier, cela signifie tout ce qu'il y a dans ce dossier et en-dessous. Pour un fichier cela signifie juste ce fichier. Normalement, la liste des chemins montre tous les chemins qui sont affectés par la même livraison, mais en gris. Si la case est cochée, ces chemins sont cachés.

Parfois, vos habitudes de travail nécessiteront que les commentaires de révision aient un format particulier, ce qui signifie que le texte résumant les modifications ne sera pas visible dans le panneau supérieur. La propriététsvn:logsummary peut être utilisée pour afficher dans le panneau supérieur une partie du commentaire de révision. Lisez la section intitulée « Propriétés de projet TortoiseSVN » pour savoir comment utiliser cette propriété.

Le bouton Statistiques fait apparaître une boîte montrant des informations intéressantes sur les révisions affichées dans la boîte de dialogue de journal. Elle montre combien d'auteurs ont travaillé, combien de livraisons ils ont fait, la progression semaine par semaine et bien d'autres. Maintenant vous pouvez voir du premier coup d'œil qui a travaillé le plus dur et qui se relâche ;-)

Page de livraisons par auteur

Figure 4.25. Histogramme de livraisons par auteur

Ce graphique vous montre quels auteurs ont été actifs sur le projet par un histogramme simple, un histogramme empilé ou un camembert.

Figure 4.26. Camembert de livraisons par auteur

Quand il y a quelques auteurs principaux et beaucoup de contributeurs mineurs, le nombre de segments minuscules peut rendre le graphique plus difficile à lire. Le curseur de défilement en bas vous permet de définir un seuil (en pourcentage du total des livraisons) en-dessous duquel toutes les activités sont regroupées dans une catégorie Autres.

Page de livraisons par date

Figure 4.27. Graphique de livraisons par date

Cette page vous donne une représentation graphique de l'activité du projet en termes de nombre de livraisons et d'auteurs. Cela donne une certaine idée de quand un projet est actif et de qui travaillait à quel moment.

Quand il y a plusieurs auteurs, vous obtiendrez beaucoup de lignes sur le graphique. Il y a deux vues disponibles ici : normale, où l'activité de chaque auteur est relative à la ligne de base et empilée, où l'activité de chaque auteur est relative à la ligne d'en dessous. La dernière option évite les lignes qui se traversent, ce qui peut rendre le graphique plus facile à lire, mais la production d'un auteur moins facile à voir.

Par défaut l'analyse est sensible à la casse donc les utilisateurs PeterEgan et PeteRegan sont considérés comme des auteurs différents. Cependant, dans de nombreux cas les noms des utilisateurs ne sont pas sensibles à la casse et sont parfois saisis de façon variable, donc vous pourriez vouloir que DavidMorgan et davidmorgan soient considérés comme la même personne. Utilisez la case à cocher Auteurs non sensibles à la casse pour contrôler la manière dont cela est traité.

Notez que les statistiques couvrent la même période que la boîte de dialogue de journal. Si cela ne concerne qu'une révision alors les statistiques ne vous diront pas grand-chose.

Figure 4.28. Fenêtre de mode hors ligne

Si le serveur est inaccessible, et que vous avez activé la mise en cache des commentaires de révision, vous pouvez utiliser la boîte de dialogue de journal et le graphique des révisions en mode hors ligne. Ces outils utiliseront alors les données mises en cache, ce qui vous permet de continuer à travailler même si les informations sont incomplètes ou ne sont pas à jour.

Vous avez ici trois choix :

La case à cocher Définir comme choix par défaut empêche cette boîte de dialogue de réapparaître et retient toujours l'option choisie par la suite. Vous pouvez toujours modifier (ou supprimer) cette valeur par défaut plus tard dans le menu TortoiseSVN → Paramètres.

Si vous voulez vérifier si de nouveaux commentaires sont arrivés sur le serveur, vous pouvez simplement rafraîchir l'affichage en appuyant sur F5. Si vous utilisez le cache pour les commentaires (ce qui est le comportement par défaut), cette vérification se fera et seuls les nouveaux commentaires seront rapatriés. Si le cache des commentaires était en mode hors ligne, il tentera de se reconnecter.

Si vous utilisez le cache du journal et si vous pensez que le contenu du message ou son auteur ont pu changer, vous pouvez utiliser Maj-F5 ou Ctrl-F5 pour récupérer à nouveau les messages affichés à partir du serveur et mettre à jour le cache du journal. Notez que ceci affecte uniquement les messages affichés à cet instant et que ceci n'invalide pas le cache complet pour ce dépôt.

Si vous avez configuré un outil de diff alternatif, vous pouvez utiliser la touche Maj quand vous sélectionnez la commande Diff pour utiliser l'outil alternatif. Lisez la section intitulée « Réglages des programmes externes » pour savoir comment configurer les autres outils de diff.

Parfois dans la vie d'un projet il se peut que vous modifiiez les fins de ligne de CRLF en LF, ou que vous changiez l'indentation d'une section. Malheureusement ceci va marquer un grand nombre de lignes comme étant modifiées, bien qu'il n'y ait pas de changement à la signification du code. Ces options vont aider à gérer ces modifications lorsqu'il s'agira de comparer et d'appliquer des différences. Vous pourrez voir ces réglages dans les boîtes de dialogue Fusionner et Annoter, tout comme dans les paramètres de TortoiseMerge.

Ignorer les fins de ligne exclut les modifications qui ne concernent que le style des caractères de fin de ligne.

Comparer les espacements inclut les modifications d'indentation et d'espaces à la liste des lignes ajoutées/supprimées.

Ignorer les changements d'espaces exclut les changements dus uniquement à une modification du nombre ou du type d'espaces, par exemple un changement d'indentation ou le passage des tabulations aux espaces. Ajouter un espace où il n'y en avait pas précédemment, ou supprimer complètement un espace est toujours indiqué comme un changement.

Ignorer tous les caractères d'espacement exclut toutes les modifications qui ne concernent que des caractères d'espacement.

Naturellement, chaque ligne modifiée est toujours incluse dans le diff.

Figure 4.29. La boîte de dialogue Comparer les révisions

Quand vous sélectionnez deux arborescences dans l'explorateur de dépôt ou quand vous sélectionnez deux révisions d'un dossier dans la boîte de dialogue de journal, vous pouvez Menu contextuel → Comparer les révisions.

Cette boîte de dialogue affiche une liste des fichiers modifiés et vous permet de les comparer ou de les annoter individuellement en utilisant le menu contextuel.

Vous pouvez exporter un arbre des modifications, qui est utile si vous avez besoin d'envoyer la structure de l'arbre de votre projet à un tiers, contenant uniquement les fichiers qui ont été modifiés. Cette opération fonctionne sur les fichiers sélectionnés uniquement, ainsi vous devez sélectionner les fichiers qui vous intéressent — ce qui signifie souvent tous les fichiers — puis ensuite sélectionner Menu contextuel → Exporter la sélection vers.... Vous serez invités à choisir un emplacement où sauvegarder l'arbre des modifications.

Vous pouvez également exporter la liste des fichiers modifiés dans un fichier texte en utilisant Menu contextuel → Enregistrer la liste des fichiers sélectionnés vers....

Si vous voulez exporter la liste des fichiers et aussi les actions (modifié, ajouté, supprimé), vous pouvez le faire en utilisant Menu contextuel → Copier la sélection dans le presse-papiers.

Le bouton en haut vous permet de modifier le sens de la comparaison. Vous pouvez afficher les changements nécessaires pour arriver de A vers B, ou si vous préférez, de B vers A.

Les boutons avec les numéros de révision peuvent être utilisés pour passer à un éventail de révisions différent. Lorsque vous changez d'éventail, la liste des éléments qui diffèrent entre les deux révisions sera mise à jour automatiquement.

Si la liste des noms de fichier est très longue, vous pouvez utiliser le champ de recherche pour limiter la liste aux noms de fichiers contenant un texte donné. Remarque : la boîte de dialogue utilise une recherche texte simple, donc si vous voulez restreindre la liste aux fichiers C vous devrez saisir .c et non *.c.

Il y a beaucoup d'outils disponibles pour comparer des fichiers texte, y compris notre propre TortoiseMerge, mais souvent, nous voulons également voir les modifications effectuées sur un fichier image. C'est pourquoi nous avons créé TortoiseIDiff.

Figure 4.30. Le visualiseur de différences d'images

TortoiseSVN → Voir les différences pour n'importe quel format d'image commun démarrera TortoiseIDiff pour afficher les différences d'image. Par défaut les images sont affichées côte à côte mais vous pouvez utiliser le menu Affichage ou la barre d'outils pour basculer vers une vue haut-bas à la place, ou si vous préférez, vous pouvez superposer les images et faire comme si vous compariez deux calques par transparence.

Naturellement vous pouvez aussi faire un zoom avant et arrière et vous déplacer sur l'image. Vous pouvez également effectuer un mouvement panoramique de l'image en la faisant glisser avec le bouton gauche. Si vous sélectionnez l'option Lier les images ensemble, alors les contrôles de déplacement (barre de défilement, molette) des deux images sont reliés.

Dans l'image, une boîte d'informations affiche les détails concernant le fichier image, comme la taille en pixels, la résolution et la profondeur des couleurs. Si cette boîte vous gêne, utilisez Affichage → Informations de l'image pour la masquer. Vous pouvez obtenir la même information dans une info-bulle lorsque vous passez la souris sur la barre de titre de l'image.

Lorsque les images sont superposées, l'intensité relative des images (transparence) est contrôlée grâce à un ascenseur situé sur la gauche. Vous pouvez directement cliquer n'importe où sur l'ascenseur, ou faire glisser le curseur pour modifier interactivement sa valeur. Ctrl+Maj-Roulette pour modifier la transparence.

Le bouton au dessus de l'ascenseur permet de passer de 0% à 100% de transparence, et si vous double-cliquez dessus, la transparence change automatiquement chaque seconde jusqu'à ce que vous cliquiez de nouveau. Cela peut être utile lorsque vous cherchez beaucoup de petites modifications.

Parfois vous voulez voir une différence plutôt qu'un mélange. Vous pourriez avoir les fichiers d'images de deux révisions d'un circuit imprimé et souhaiter voir quelles pistes ont changé. Si vous désactivez le mode alpha blend, la différence sera présentée comme un XOR de la valeur des pixels de couleur. Les zones inchangées seront blanches et les changements apparaîtront en couleur.

Quand vous voulez comparer des documents binaires, vous devez normalement utiliser le logiciel que vous avez utilisé pour créer le document, puisqu'il comprend le format de fichier. Pour les suites bureautiques couramment utilisées Microsoft Office et Open Office, il y a effectivement des fonctionnalités d'affichage de différences, et TortoiseSVN inclut des scripts pour les appeler avec les bons paramètres quand vous comparez des fichiers avec les extensions connues. Vous pouvez vérifier quelles extensions de fichier sont supportées et en ajouter en allant dans TortoiseSVN → Configuration et en cliquant sur Avancé dans la section Visualiseur de différences.

Si les outils que nous fournissons ne font pas ce dont vous avez besoin, essayez un des nombreux programmes open-source ou commerciaux disponibles. Chacun a ses préférences et cette liste n'est en aucun cas exhaustive, mais en voici quelques-uns intéressants :

Lisez la section intitulée « Réglages des programmes externes » pour des informations sur la façon de configurer TortoiseSVN pour utiliser ces outils.

Les modèles d'exclusion de Subversion se servent de l'expansion des jokers (globbing) dans les noms de fichier, une technique à l'origine utilisée sous Unix pour spécifier des fichiers utilisant des méta-caractères comme caractères de remplacement. Les caractères suivants ont une signification spéciale :

La correspondance avec des modèles est sensible à la casse, ce qui peut causer des problèmes sous Windows. Vous pouvez forcer l'insensibilité à la casse à la dure en appariant les caractères. Par exemple, pour ignorer *.tmp quelle que soit la casse, vous pouvez utiliser un modèle comme *.[Tt][Mm][Pp].

Si vous voulez une définition officielle pour l'expansion de jokers (globbing), vous pouvez la trouver dans les spécifications IEEE pour le langage de commande d'interpréteur de commandes Pattern Matching Notation.

Utilisez TortoiseSVN → Supprimer pour enlever des fichiers ou des dossiers de Subversion.

Quand vous faites TortoiseSVN → Supprimer sur un fichier ou un dossier, il est immédiatement effacé de votre copie de travail et marqué pour suppression dans le dépôt à la prochaine livraison. Le dossier parent de l'élément affiche l'icône superposée de l'état « modifié ». Tant que vous n'avez pas livré la modification, vous pouvez récupérer le fichier en utilisant TortoiseSVN → Revenir en arrière sur le répertoire parent.

Si vous voulez supprimer un élément dans le dépôt, mais le conserver localement comme un fichier/répertoire non versionné, utilisez Menu contextuel étendu → Supprimer (conserver localement). Vous devez tenir la touche Maj enfoncée tout en effectuant un clic droit avec la souris sur l'élément désiré dans le volet de l'explorateur (volet droit) afin de voir cette commande dans le menu contextuel étendu.

Si un élément est effacé depuis l'explorateur au lieu d'utiliser le menu contextuel de TortoiseSVN, la boîte de dialogue de livraison signale ces éléments comme manquants et vous permet de les retirer de la gestion de version avant la livraison. Cependant, si vous faites une mise à jour de votre copie de travail, Subversion détectera l'élément manquant et le remplacera avec la dernière version du dépôt. Si vous avez besoin de supprimer un fichier versionné, utilisez toujours TortoiseSVN → Supprimer pour que Subversion ne soit pas obligé de deviner ce que vous cherchez réellement à faire.

Si vous voulez faire un simple renommage d'un fichier ou d'un dossier sans changer son emplacement, utilisez Menu contextuel → Renommer... Entrez le nouveau nom de l'élément et vous avez terminé.

Si vous voulez déplacer des fichiers dans votre copie de travail, peut-être vers un sous-dossier différent, utilisez le glisser-déposer avec le bouton droit :

Une autre façon de déplacer ou de copier des fichiers est d'utiliser les commandes copier/couper de Windows. Sélectionnez les fichiers que vous voulez copier, faites un clic droit et choisissez Menu contextuel → Copier

Vous pouvez aussi utiliser l'explorateur de dépôt pour déplacer des éléments. Lisez la section intitulée « L'explorateur de dépôt » pour en savoir plus.

Si le dépôt contient deux fichiers qui ont le même nom mais qui ne diffèrent que par la casse (par exemple TEST.TXT et test.txt), vous ne pourrez pas mettre à jour ou extraire le répertoire parent sous Windows. Bien que Subversion soit sensible à la casse dans les noms de fichiers, ce n'est pas le cas de Windows.

Cela arrive parfois lorsque deux personnes livrent, depuis des copies de travail séparées, des fichiers qui se trouvent avoir le même nom, mais avec une différence de casse. Cela peut également arriver quand les fichiers sont livrés depuis un système d'exploitation qui utilise un système de fichiers sensible à la casse, comme Linux.

Dans ce cas, vous devez décider lequel des deux vous voulez conserver et supprimer (ou renommer) l'autre du dépôt.

Parfois, votre environnement de développement va renommer des fichiers pour vous dans le cadre d'une restructuration des sources, et bien sûr il ne le dit pas à Subversion. Si vous essayez de livrer vos modifications, Subversion peut voir l'ancien nom de fichier comme manquant et le nouveau comme un fichier non versionné. Vous pourriez simplement livrer le nouveau nom de fichier pour le rajouter dans le dépôt, mais on perdrait alors l'historique, car Subversion ne sait pas que les fichiers sont liés.

Une meilleure solution est d'informer Subversion que ce changement est en fait un renommage, et vous pouvez le faire dans les boîtes de dialogue Livrer et Vérifier les modifications. Il suffit de sélectionner à la fois l'ancien nom (manquant) et le nouveau nom (sans version) et d'utiliser Menu contextuel → Réparer le déplacement pour lier les deux fichiers en tant que renommage.

Généralement vous paramétrez votre liste des ignorés pour que tous les fichiers générés soient ignorés dans Subversion. Mais que faire si vous souhaitez effacer tous les éléments ignorés pour produire une génération propre ? Généralement vous définiriez cela dans votre makefile, mais si vous êtes en train de déboguer le makefile ou de changer le système de build, il est utile d'avoir un moyen de nettoyer la plate-forme.

TortoiseSVN fournit précisément une telle option avec Menu contextuel étendu → Supprimer les éléments non versionnés.... Vous devez tenir enfoncée la touche Maj tout en effectuant un clic droit sur un dossier dans le volet de l'explorateur (volet droit) afin de voir cette commande apparaître dans le menu contextuel étendu. Cela a pour effet d'ouvrir une boîte de dialogue qui répertorie tous les fichiers non versionnés où qu'ils soient dans votre copie de travail. Vous pouvez ensuite sélectionner ou désélectionner les éléments à enlever.

Lorsque ces éléments sont supprimés, la corbeille est utilisée, donc si vous faites une erreur ici et supprimez un fichier qui aurait dû être versionné, vous pouvez toujours le récupérer.

Figure 4.37. Page de propriété de subversion

Vous pouvez lire et définir les propriétés Subversion à partir de la boîte de dialogue de propriétés de Windows, mais aussi depuis TortoiseSVN → Propriétés et au sein des listes de statut de TortoiseSVN, depuis Menu contextuel → Propriétés.

Vous pouvez ajouter vos propres propriétés, ou des propriétés avec une signification spéciale pour Subversion. Celles-ci commencent par svn:. svn:externals est une de ces propriétés ; regardez comment manipuler les éléments externes dans la section intitulée « Éléments externes ».

Pour plus d'informations à propos des propriétés dans Subversion, voyez la section sur les propriétés.

Ajouter et modifier des propriétés

Figure 4.38. Ajouter des propriétés

Pour ajouter une nouvelle propriété, cliquez d'abord sur Nouveau.... Sélectionnez le nom de la propriété voulue à partir du menu, puis remplissez les informations requises dans la boîte de dialogue de propriété spécifique. Ces boîtes de dialogue de propriétés spécifiques sont décrites plus en détail dans la section intitulée « Éditeurs de propriétés » .

Pour ajouter une propriété qui ne possède pas sa propre boîte de dialogue, choisissez Autre dans le menu Nouveau.... Ensuite, sélectionnez une propriété existante dans la liste déroulante ou saisissez un nom de propriété personnalisée.

Si vous voulez appliquer une propriété à plusieurs éléments à la fois, sélectionnez les fichiers/dossiers dans l'explorateur, puis sélectionnez Menu contextuel → Propriétés.

Si vous voulez appliquer la propriété à tous les fichiers et dossiers au-dessous du dossier actuel dans la hiérarchie , cochez la case Récursive.

Si vous voulez éditer une propriété existante, sélectionnez cette propriété dans la liste des propriétés existantes, puis cliquez sur Editer....

Si vous voulez supprimer une propriété existante, sélectionnez cette propriété dans la liste des propriétés existantes, puis cliquez sur Effacer.

La propriété svn:externals peut être utilisée pour intégrer d'autres projets du même dépôt ou d'un dépôt complètement différent. Pour plus d'informations, lisez la section intitulée « Éléments externes ».

Editer les propriétés de la révision HEAD

Parce que les propriétés sont versionnées, vous ne pouvez pas modifier les propriétés des révisions précédentes. Si vous regardez les propriétés dans la boîte de dialogue du journal (log) ou d'une révision non-HEAD dans le navigateur de dépôt, vous verrez une liste de propriétés et de valeurs, mais pas de contrôles d'édition.

TortoiseSVN a quelques propriétés spéciales de son cru et elles commencent par tsvn:.

TortoiseSVN peut s'intégrer avec certains outils de suivi de bogue. Cela utilise des propriétés qui commencent par bugtraq:. Lisez la section intitulée « Intégration avec des systèmes de gestion de bug / gestion d'incidents » pour plus d'informations.

Il peut aussi s'intégrer avec certains explorateurs de dépôt en ligne, en utilsant des propriétés qui commencent par webviewer:. Lisez la section intitulée « Intégration avec des visionneuses de dépôt web » pour plus d'informations.

Lorsque vous ajoutez un nouveau sous-dossier à une copie de travail via TortoiseSVN, toutes les propriétés de projet du dossier parent seront automatiquement ajoutées à ce nouveau dossier fils.

Certaines propriétés doivent utiliser des valeurs spécifiques, ou être formatées d'une manière spécifique afin d'être utilisées pour l'automatisation. Pour obtenir plus facilement le formatage correct, TortoiseSVN présente pour certaines propriétés particulières des boîtes de dialogue d'édition qui montrent les valeurs possibles ou qui décomposent chaque composant de la propriété.

Contenu externe

Figure 4.44. Page de propriété svn:externals

La propriété svn:externals peut être utilisée pour intégrer d'autres projets du même dépôt ou d'un dépôt complètement différent comme décrit dans la section intitulée « Éléments externes » .

Vous devez définir le nom du sous-dossier sous lequel le dossier externe est extrait, et l'URL Subversion de l'élément externe. Vous pouvez extraire un externe à sa révision HEAD, de sorte que quand l'élément externe change dans le dépôt, votre copie de travail obtiendra ces changements à la mise à jour suivante. Cependant, si vous voulez que l'externe fasse référence à une version stable particulière, alors vous pouvez spécifier la révision spécifique à utiliser. Dans ce cas, vous voudrez peut-être aussi définir cette même révision comme révision pivot. Si l'élément externe est renommé ultérieurement, alors Subversion ne pourra pas mettre à jour cet élément dans votre copie de travail. En spécifiant une révision pivot, vous dites à Subversion de rechercher un élément qui portait ce nom à la révision pivot plutôt qu'à la révision HEAD.

Le bouton Trouver la révision HEAD récupère la révision HEAD de toutes les URL externes et affiche cette révision HEAD dans la colonne de droite. Une fois que la révision HEAD est connue, un simple clic droit sur un externe vous propose la commande pour définir leur révision HEAD explicite comme révision pivot des externes sélectionnés. Si la révision HEAD n'est pas encore connue, la commande avec le clic droit commencera par récupérer la révision HEAD.

Mots-clés SVN

Figure 4.45. Page de propriété svn:keywords

Sélectionnez les mots-clés que vous voudriez voir développés dans votre fichier.

Style de caractère de fin de ligne

Figure 4.46. Page de propriété svn:eol-style

Sélectionnez le style de fin de ligne que vous souhaitez utiliser et TortoiseSVN utilisera la valeur de propriété correcte.

Intégration d'un gestionnaire d'incidents

Figure 4.47. Page de propriété tsvn:bugtraq

Taille des messages de log

Figure 4.48. Page de propriété de taille des messages de log

Ces 3 propriétés contrôlent le format des messages de log. Les 2 premières désactivent le OK dans les boîtes de dialogue de livraison et de verrouillage jusqu'à ce que le message atteigne la taille minimum. La propriété de position de bordure affiche un marqueur à la largeur de colonne définie pour servir de guide aux projets qui ont des limites de largeur à leurs messages de log. Positionner une valeur à zéro effacera la propriété.

Langue de projet

Figure 4.49. Page de propriété de langue

Choisissez la langue à utiliser pour vérifier l'orthographe des messages de log dans la boîte de dialogue de livraison. La case à cocher de listes de fichier entre en compte quand vous faites un clic droit sur le volet de message de log et que vous sélectionnez Coller la liste de fichiers. Par défaut, le statut Subversion sera affiché dans votre langue locale. Quand cette case est cochée, le statut est toujours fourni en anglais, pour les projets qui requièrent des messages de log uniquement en anglais.

Type MIME

Figure 4.50. Page de propriété svn:mime-type

svn:needs-lock

Figure 4.51. Page de propriété svn:needs-lock

Cette propriété contrôle simplement si un fichier sera extrait en mode lecture seule en l’absence d'un verrou pour ce fichier dans la copie de travail.

svn:executable

Figure 4.52. Page de propriété svn:executable

Cette propriété contrôle si le statut exécutable sera donné à un fichier lorsqu'il sera extrait sur un système Unix/Linux. Cela n'a pas d'effet sur une extraction sous Windows.

Fusionner les modèles de message de journal

Quand des révisions sont fusionnées dans une copie de travail, TortoiseSVN génère un message de log à partir de toutes les révisions fusionnées. Ces messages sont alors disponibles depuis le bouton Messages récents dans la boîte de dialogue de livraison.

Vous pouvez personnaliser le message généré avec les propriétés suivantes :

Figure 4.53. Boîte de dialogue de propriété de modèles de message de fusion

tsvn:mergelogtemplatetitle, tsvn:mergelogtemplatereversetitle

Cette propriété spécifie la première partie du message de journal généré. On peut utiliser les mots-clés suivants :

{revisions}

Une liste séparée par des virgules des révisions fusionnées, par exemple 3, 5, 6, 7

{revisionsr}

Comme {revisions}, mais avec chaque révision précédée d'un r, par exemple r3, r5, r6, r7

{revrange}

Une liste séparée par des virgules des révisions fusionnées, regroupées dans des plages quand c'est possible, par exemple 3, 5-7

{mergeurl}

L'URL source de la fusion, c'est-à-dire à partir de laquelle les révisions sont fusionnées.

La valeur par défaut pour cette chaîne est Merged revision(s) {revrange} from {mergeurl}: avec un retour à la ligne à la fin.

tsvn:mergelogtemplatemsg

Cette propriété spécifie à quoi devrait ressembler le texte pour chaque révision fusionnée. On peut utiliser les mots-clés suivants :

{msg}

Le message de journal de la révision fusionnée, tel qu'il a été saisi.

{msgoneline}

Comme {msg}, mais tous les retours à la ligne sont remplacés par des espaces, de sorte que l'ensemble du message de journal apparaît sur une seule ligne.

{author}

L'auteur de la révision fusionnée.

{rev}

La révision fusionnée elle-même.

{bugids}

Les ID de bogues de la révision fusionnée, s'il en existe.

tsvn:mergelogtemplatemsgtitlebottom

Cette propriété spécifie la position de la chaîne titre spécifiée dans la propriété tsvn:mergelogtemplatetitle ou tsvn:mergelogtemplatereversetitle. Si la propriété est positionnée à yes (oui) ou true (vrai), alors la chaîne titre est ajoutée à la fin au lieu du début.

Important

Cela ne fonctionne que si les révisions fusionnées sont déjà dans le cache du journal. Si vous avez désactivé le cache du journal ou que vous n'avez pas affiché le journal avant la fusion, le message généré ne contiendra aucune information sur les révisions fusionnées.

Disons que vous avez extrait une copie de travail de /projet1 dans D:\dev\projet1. Sélectionnez le dossier D:\dev\projet1, faites un clic droit et choisissez menu Windows → Propriétés dans le menu contextuel. La boîte de dialogue de Propriétés apparaît. Allez ensuite sur l'onglet Subversion. Ici, vous pouvez positionner des propriétés. Cliquez sur Propriétés.... Dans la boîte de dialogue de propriétés, double-cliquez sur le svn:externals s'il existe déjà, ou cliquez sur le bouton Nouveau... et sélectionnez Références externes dans le menu. Pour ajouter un nouvel externe, cliquez sur Nouveau... et saisissez les informations requises dans la boîte de dialogue.

Si vous souhaitez que le chemin local contienne des espaces ou d'autres caractères spéciaux, vous pouvez les encadrer avec des guillemets doubles, ou vous pouvez utiliser le caractère \ (antislash) comme caractère d'échappement avant un caractère spécial, comme dans le shell Unix. Bien entendu, cela signifie que vous devez utiliser / (slash) comme délimiteur de chemin. Notez que ce comportement est nouveau dans Subversion 1.6 et ne fonctionnera pas avec les versions antérieures.

Si le projet externe est dans le même dépôt, les changements que vous y faites seront inclus dans la liste de livraisons quand vous livrerez votre projet principal.

Si le projet externe est dans un dépôt différent, les changements que vous faites au projet externe seront signalés quand vous livrerez le projet principal, mais vous devrez livrer ces changements externes séparément.

Si vous utilisez des URL absolues dans la valeur de l'option svn:externals and que vous relocalisez votre copie de travail (c'est-à-dire si l'URL de votre dépôt change), alors vos références externes ne seront pas mises à jour et risquent de ne plus fonctionner.

Pour éviter de tels problèmes, à partir de la version 1.5 du client, Subversion permet d'utiliser les chemins relatifs dans les références externes. Quatre méthodes différentes de spécification d'URL relatives sont supportées. Dans les exemples suivants, considérez qu'il y a deux dépôts : un premier à l'adresse http://example.com/svn/depot-1 et un second à l'adresse http://example.com/svn/depot-2. Nous avons une extraction de http://example.com/svn/depot-1/projet/trunk dans C:\Travail et la propriété svn:externals est positionnée sur le trunk.

Si nécessaire, vous pouvez aussi spécifier une révision pivot et une révision opérationnelle pour l'URL. Pour plus d'informations sur les révisions pivot et les révisions opérationnelles, veuillez lire le chapitre correspondant dans le livre de Subversion.

Si vous avez besoin de plus d'informations sur la façon dont TortoiseSVN manipule les propriétés, lisez la section intitulée « Configuration des projets ».

Pour découvrir des méthodes différentes d'accéder aux sous-projets communs, lisez la section intitulée « Inclure un sous-projet commun ».

À partir de Subversion 1.6, vous pouvez ajouter à votre copie de travail des références externes relatives à des fichiers en utilisant la même syntaxe que pour les dossiers. Il y a néanmoins quelques limitations.

Par beaucoup d'aspects, les fichiers externes se comportent comme n'importe quel autre fichier versionné. Néanmoins, ils ne peuvent pas être déplacés ou supprimés avec les commandes standard ; il faut passer par la modification de la propriété svn:externals.

Si vous avez déjà une copie de travail des fichiers ou des dossiers que vous voulez inclure en tant que références externes dans une autre copie de travail, vous pouvez simplement les ajouter en faisant un glisser-déposer depuis l'explorateur Windows.

Faites simplement glisser avec le bouton droit le fichier ou le dossier depuis une copie de travail jusqu'à l'emplacement où vous voulez les inclure en tant que références externes. Un menu contextuel apparaît quand vous relâchez le bouton de la souris. Si vous cliquez sur l'élément SVN Ajouter comme référence externe ici de ce menu contextuel, la propriété svn:externals est ajoutée automatiquement. Tout ce qu'il vous reste à faire après cela est de livrer les changements de propriété et de mettre à jour pour que ces références externes soient incluses correctement dans votre copie de travail.

Si vous avez importé votre projet avec la structure de répertoire recommandée, créer une branche ou une étiquette est très simple :

Figure 4.54. La boîte de dialogue Branche/étiquette

Sélectionnez le dossier de votre copie de travail que vous voulez copier dans une branche ou une étiquette, et choisissez ensuite la commande TortoiseSVN → Branche/étiquette....

Par défaut, l'URL de destination de la nouvelle branche sera l'URL source sur laquelle votre copie de travail est basée. Vous devrez éditer cette URL pour indiquer le nouveau chemin vers votre branche/étiquette. Ainsi, au lieu de

http://svn.collab.net/depot/NomDeProjet/trunk
      

vous allez peut-être passer à quelque chose comme

http://svn.collab.net/depot/NomDeProjet/tags/Release_1.10
      

Si vous ne vous souvenez pas de la convention de nommage que vous avez utilisée la dernière fois, cliquez sur le bouton à droite pour ouvrir l'explorateur de dépôt et voir la structure existante du dépôt.

Maintenant vous devez choisir la source de la copie. Ici vous avez trois options :

Si vous voulez que votre copie de travail soit basculée automatiquement sur la branche nouvellement créée, utilisez la case à cocher Déplacer la copie de travail vers une nouvelle branche/étiquette. Mais si vous le faites, assurez-vous d'abord que votre copie de travail ne contient pas de modifications. Si c'est le cas, ces changements seront fusionnés dans la CdT de branche quand vous basculerez.

Si votre copie de travail contient d'autres projets incluant des propriétés svn:externals, ces ressources externes seront énumérées au bas de la fenêtre de branche/étiquette. Pour chaque ressource externe, le chemin cible et l'URL source sont affichés.

Si vous voulez vous assurer que la nouvelle étiquette est toujours dans un état cohérent, vérifiez toutes les références externes pour que leurs révisions soient épinglées. Si vous ne vérifiez pas les références externes et que ces références externes pointent vers une révision HEAD qui peut changer dans l'avenir, extraire la nouvelle étiquette extraira cette révision HEAD de la référence externe et votre étiquette pourrait ne plus compiler. Donc c'est toujours une bonne idée de positionner les références externes à une révision explicite en créant une étiquette.

Les éléments externes sont automatiquement épinglé soit à la révision courante de tête soit à la révision de travail de base, selon la source de la branche/tag :

Appuyez sur OK pour livrer la nouvelle copie dans le dépôt. N'oubliez pas de mettre un commentaire. Notez que la copie est créée dans le dépôt.

Notez qu'à moins que vous choisissiez de basculer votre copie de travail vers la branche juste créée, créer une branche ou une étiquette ne modifie pas votre copie de travail. Même si vous créez la branche depuis votre CdT, ces changements sont livrés dans la nouvelle branche, pas dans le trunk, donc votre CdT peut toujours être marquée comme modifiée par rapport au trunk.

Vous pouvez aussi créer une branche ou une étiquette sans avoir de copie de travail. Pour ce faire, ouvrez l'explorateur de dépôt. Vous pouvez faire glisser des répertoires vers un nouvel endroit. Pour créer une copie, vous devez garder la touche Ctrl appuyée lorsque vous faites glisser le répertoire, sinon celui-ci n'est pas copié, mais déplacé.

Vous pouvez également faire glisser un dossier avec le bouton droit de la souris. Dès que vous relâchez le bouton, un menu contextuel s'affiche pour vous permettre de choisir entre la copie ou le déplacement du dossier. Bien sûr, pour créer une branche ou une étiquette, vous devez copier le dossier, pas le déplacer.

Il y a une autre façon de faire dans la boîte de dialogue de journal. Vous pouvez afficher la boîte de dialogue de journal, par exemple du trunk, sélectionner une révision (soit la révision HEAD tout en haut, soit une révision antérieure), faire un clic droit et choisir Créer une branche/étiquette depuis une révision.

... telle (n')est (pas) la question. Tandis qu'une extraction extrait tout de la branche désirée du dépôt dans votre répertoire de travail, TortoiseSVN → Aller sur... transfère seulement les données modifiées dans votre copie de travail. Bon pour la charge réseau, bon pour votre patience. :-)

Pour pouvoir travailler avec votre branche ou votre étiquette récemment générée, vous avez plusieurs méthodes. Vous pouvez :

Figure 4.55. La boîte de dialogue Aller sur

Bien que Subversion lui-même ne fasse aucune distinction entre les étiquettes et les branches, la manière dont elles sont typiquement utilisées diffère un peu.

Figure 4.56. Assistant de fusion — Sélectionner une plage de révisions

Dans le champ De : entrez l'URL complète du dossier de la branche ou de l'étiquette contenant les changements que vous voulez reporter dans votre copie de travail. Vous pouvez aussi cliquer sur ... pour parcourir le dépôt et trouver la branche désirée. Si vous avez déjà fusionné depuis cette branche, alors utilisez simplement la liste déroulante contenant l'historique des URLs déjà utilisées.

Si vous fusionnez depuis une branche renommée ou effacée, alors vous devrez retourner à une révision où cette branche existait encore. Dans ce cas, vous devez aussi spécifier cette révision comme révision pivot dans la plage des révisions fusionnées (voir ci-dessous), sinon la fusion échouera quand elle ne pourra pas trouver ce chemin à la révision HEAD.

Dans le champ texte Plage de révisions à fusionner entrez la liste des révisions à fusionner. Ce peut être une seule révision, une liste de révisions spécifiques séparées par des virgules, une plage de révisions séparées par un tiret, ou une combinaison de ces différentes notations.

Si vous avez besoin de spécifier une révision pivot pour la fusion, ajoutez la révision pivot à la fin des révisions, ex. :5-7,10@3. Dans l'exemple ci-dessus, les révisions 5,6,7 et 10 seront fusionnées, avec 3 comme révision pivot.

La façon la plus facile de choisir la plage de révisions dont vous avez besoin est de cliquer sur Voir le journal, puisqu'ainsi les changements récents seront affichés avec les commentaires associés. Si vous voulez fusionner les changements d'une seule révision, sélectionnez juste cette révision. Si vous voulez fusionner les changements de plusieurs révisions, alors sélectionnez cette plage (en utilisant comme de coutume la touche Maj). Cliquez sur OK et les numéros de révision seront automatiquement insérés.

Si vous voulez revenir sur des modifications déjà fusionnées dans votre copie de travail, sélectionnez les révisions à annuler et vérifiez bien que la case Fusion inversée est cochée.

Si vous avez déjà fusionné des changements de cette branche, avec bon espoir vous aurez fait une note de la dernière révision fusionnée dans le commentaire quand vous avez livré la modification. Dans ce cas, vous pouvez utiliser Voir le journal dans la copie de travail pour retrouver ce commentaire. Dans la mesure où nous considérons les révisions comme des listes de modifications, vous devriez utiliser la révision de fin de la dernière fusion comme point de départ pour celle ci. Par exemple, si vous avez fusionné les révisions 37 à 39 la dernière fois, alors le point de départ pour cette fusion devrait être la révision 40.

Si vous vous servez de la fonctionnalité de suivi de fusion de Subversion, vous n'avez pas besoin de vous souvenir des révisions déjà fusionnées — Subversion les enregistrera pour vous. Si vous laissez le champ plage de révisions vide, toutes les révisions qui n'ont pas encore été fusionnées y seront listées. Lisez la section intitulée « Suivi de fusion » pour en savoir plus.

Quand le suivi de fusion est utilisé, la boîte de dialogue de journal montrera les révisions précédemment fusionnées, et les révisions antérieures à l'ancêtre commun, c'est-à-dire avant la copie de la branche, en grisé. La case à cocher Cacher les révisions ne pouvant être fusionnées vous permet de filtrer complètement ces révisions, afin que vous ne voyiez que les révisions qui peuvent être fusionnées.

Si d'autres personnes peuvent livrer des changements alors soyez prudents en utilisant la révision HEAD. Elle peut ne pas faire référence à la révision à laquelle vous pensez si quelqu'un d'autre a fait une livraison après votre dernière mise à jour.

Si vous laissez vide la plage de révisions ou que vous sélectionnez le bouton radio toutes les révisions, alors Subversion fusionne toutes les révisions qui ne l'ont pas encore été. On appelle cela une réintégration ou une fusion automatique.

Il y a quelques prérequis pour pouvoir faire une réintégration. Premièrement, le serveur doit supporter le suivi de fusion. La copie de travail doit contenir toute la profondeur complète de l'arborescence (pas d'extractions partielles), et elle ne doit pas avoir de modifications locales, d'éléments déplacés ou mis à jour à une révision autre que HEAD. Tous les changements faits sur le trunk pendant la phase de développement de la branche doivent avoir été intégrés à la branche (ou marqués comme ayant été fusionnés). La plage de révisions à fusionner sera calculée automatiquement.

Cliquez sur Suivant et aller à la section intitulée « Options de fusion ».

Figure 4.57. Assistant de fusion — fusion d'arborescence

Si vous utilisez cette méthode pour fusionner une branche avec le trunk, vous devez démarrer l'assistant de fusion depuis une copie de travail du trunk.

Dans le champ De : entrez l'URL complète du dossier du trunk. Cela peut sembler erroné, mais souvenez-vous que le trunk est l'endroit auquel vous souhaitez ajouter les modifications de la branche. Vous pouvez aussi cliquer sur ... pour parcourir le dépôt.

Remplissez le champ À : avec l'adresse complète de la branche.

Dans les deux champs Depuis la révision et À la révision, entrez le numéro de la dernière révision à laquelle les deux arbres ont été synchronisés. Si vous êtes sûrs que personne d'autre ne fait de livraison vous pouvez utiliser la révision HEAD dans les deux cas. S'il y a une chance que quelqu'un d'autre ait fait une livraison depuis cette synchronisation, utilisez le numéro spécifique de la révision pour éviter de perdre des livraisons plus récentes.

Vous pouvez également utiliser Voir le journal pour sélectionner la révision.

Cette page de l'assistant vous permet de spécifier des options avancées avant de commencer le processus de fusion. La plupart du temps vous pouvez vous contenter d'utiliser les options par défaut.

Vous pouvez donner la profondeur de fusion, c'est-à-dire à quelle profondeur dans la copier de travail la fusion doit aller. Les termes de profondeur utilisés sont décrits dans la section intitulée « Profondeur d'extraction ». La profondeur par défaut est Copie de travail, qui utilise le paramètre existant de profondeur, et c'est presque toujours ce dont vous avez besoin.

La plupart du temps, vous voulez que la fusion prenne en compte l'historique du fichier, afin que les changements relatifs à un ancêtre commun soient fusionnés. Parfois vous pouvez avoir besoin de fusionner des fichiers qui sont apparentés, mais pas dans votre dépôt. Par exemple, vous pouvez avoir importé les versions 1 et 2 d'une bibliothèque tierce partie dans deux répertoires différents. Bien qu'ils soient apparentés logiquement, Subversion ne le sait pas parce qu'il ne voit que les archives que vous avez importées. Si vous essayiez de fusionner les différences entre ces deux arborescences, vous verriez une suppression complète suivi d'un ajout complet. Pour dire à Subversion de n'utiliser que les différences basées sur le chemin plutôt que les différences basées sur l'historique, cochez la case Ignorer l'ascendance. Vous pouvez en lire plus sur ce sujet dans le livre de Subversion, Prise en compte ou non de l'ascendance.

Vous pouvez spécifier la gestion des changements de caractères de fin de ligne et d'espacement. Ces options sont décrites dans la section intitulée « Options de fins de ligne et d'espacement ». Le comportement par défaut est de considérer toutes les différences d'espaces et de fins de lignes comme des modifications à part entière, qu'il faut livrer.

La case à cocher Forcer la fusion est utilisée pour éviter un conflit d'arborescence lors de la suppression d'un fichier qui a été modifié localement ou qui n'est pas sous contrôle de version. Si le fichier est supprimé, il n'y a aucun moyen de le récupérer, ce qui explique que par défaut cette case ne soit pas cochée.

Si vous utilisez la fonction de suivi de fusion et que vous souhaitez marquer une révision comme ayant été fusionnée, sans vraiment avoir fait de fusion ici, cochez la case Enregistrer uniquement la fusion. Il y a deux raisons pour lesquelles vous pourriez être amenés à faire ceci. La fusion à effectuer est trop compliquée pour les algorithmes de fusion, vous faites donc la fusion à la main et marquez les modifications comme ayant été fusionnées de manière à ce que le suivi de fusion le sache. Ou vous voulez éviter qu'une révision particulière soit fusionnée. La marquer comme ayant été fusionnée empêchera les clients supportant le suivi de fusion de faire effectivement la fusion.

A présent que tout est correctement configuré, tout ce que vous avez à faire est de cliquer sur le bouton Fusionner. Si vous voulez avoir un aperçu du résultat, le bouton Tester la fusion simulera la fusion sans modifier la CdT. La liste des fichiers qui seront changés par une vraie fusion s'affichera, ainsi que les endroits où il pourrait y avoir des conflits. Comme le suivi de fusion rend le processus de fusion beaucoup plus complexe, il n'est pas possible de savoir à l'avance avec certitude si la fusion sera réalisée sans conflit, donc les fichiers marqués comme étant en conflit dans un test de fusion pourraient en fait fusionner sans aucun problème.

La boîte de dialogue de progression de la fusion vous montre chaque étape de la fusion, avec les plages de révisions concernées. Elle peut indiquer une révision de plus que ce à quoi vous vous attendiez. Par exemple, si vous avez demandé de fusionner la révision 123, la boîte de dialogue de progression affichera « Fusion des révisions 122 à 123 ». Pour le comprendre, il faut vous souvenir que la fusion est apparentée à la comparaison. Le processus de fusion génère une liste de différences entre deux points dans le dépôts, puis applique ces différences à votre copie de travail. La boîte de dialogue de progression vous montre simplement les points de départ et d'arrivée de la comparaison.

La fusion est à présent effectuée. C'est une bonne idée d'aller regarder le résultat et de vérifier que tout est conforme à vos attentes. Fusionner est normalement assez compliqué. Il y a souvent des conflits si la branche s'est beaucoup éloignée du trunk.

Pour les clients et serveurs Subversion antérieurs à la version 1.5, aucune information de fusion n'est conservée et il faut aller rechercher manuellement les révisions à fusionner. Une fois que vous avez testé les changements et que vous allez livrer cette révision, le commentaire de livraison devrait toujours inclure les numéros de révision inclus dans la fusion. Si vous voulez faire une autre fusion plus tard, vous aurez besoin de savoir ce que vous avez déjà fusionné pour ne pas appliquer vos modifications plusieurs fois. Pour plus d'informations, consultez Best Practices for Merging dans le livre de Subversion [NdT : version 1.4 non traduite en français].

Pour des clients et serveurs Subversion en version 1.5 ou postérieure, la fonctionnalité de suivi de fusion enregistrera les révisions fusionnées et empêchera de fusionner une même révision plusieurs fois. Cela vous simplifie considérablement la tâche, dans la mesure où vous pouvez simplement fusionner toute la plage de révisions à chaque fois en étant sûr que seules les nouvelles révisions seront vraiment fusionnées.

La gestion de branches est importante. Si vous voulez conserver une branche synchronisée avec le tronc, vous devrez vous assurer de fusionner souvent de sorte que la branche et le tronc ne soient pas trop éloignés. Bien sûr, vous devez toujours éviter de fusionner plusieurs fois les mêmes modifications comme expliqué ci-dessus.

La version 1.5 de Subversion a introduit des aides au suivi de fusion. Lorsque vous fusionnez des modifications depuis une arborescence vers une autre, les numéros de révision sont stockés et cette information peut être utilisée à plusieurs fins.

Les informations de suivi de fusion sont stockées dans la propriété svn:mergeinfo par le client lorsqu'il effectue la fusion. Au moment de la livraison de cette fusion, le serveur stocke l'information dans la base de données, et quand vous souhaitez fusionner, commenter ou annoter, le serveur peut répondre de manière appropriée. Afin que le système fonctionne correctement, vous devez vous assurer que le serveur, le dépôt et les clients sont à jour. Les clients plus anciens ne stockeront pas la propriété svn:mergeinfo et les serveurs plus anciens ne pourront pas fournir l'information demandée par les clients récents.

Apprenez-en plus sur le suivi des fusions dans la Documentation du suivi des fusions de Subversion.

Une fusion ne se passe pas toujours très bien. Il y a parfois un conflit. TortoiseSVN vous aide à suivre ce processus en vous montrant la boîte de dialogue de conflit de fusion.

Figure 4.58. La boîte de dialogue de conflit de fusion

Il est probable que certains changements auront été fusionnés sans difficulté, mais que d'autres changements locaux seront en conflit avec les changements déjà livrés dans le dépôt. Tous les changements qui peuvent être fusionnés le sont. La boîte de dialogue de conflit de fusion vous donne plusieurs façons de gérer les lignes qui sont en conflit.

Pour les conflits normaux qui se produisent à cause de changements dans le contenu du fichier ou dans ses propriétés, la boîte de dialogue contient des boutons qui vous permettent de choisir ce que vous voulez garder ou rejeter parmi les parties en conflit.

S'il y a un conflit d'arborescence, veuillez d'abord consulter la section intitulée « Conflits d'arborescence » à propos des différents types de conflits d'arborescence et de comment et pourquoi ils se produisent.

Pour résoudre les conflits d'arborescence après une fusion, une boîte de dialogue est affichée avec différentes options sur comment résoudre le conflit :

Figure 4.59. La boîte de dialogue de fusion de conflit d'arborescence

Comme il y a plusieurs situations possibles de conflit d'arborescence, les boutons affichés dans la boîte de dialogue pour résoudre ces situations dépendront du conflit concerné. Les textes et libellés des boutons expliquent ce que fait l'option pour résoudre le conflit. Si vous n'êtes pas sûr de vous, vous pouvez soit annuler la boîte de dialogue, soit utiliser le bouton Report pour résoudre le conflit plus tard.

Quand vous développez une nouvelle fonctionnalité dans une branche séparée, c'est une bonne pratique de prévoir une politique de réintégration de cette branche lorsque la nouvelle fonctionnalité sera prête. Si la branche principale — trunk — évolue en même temps, il est probable que les différences seront nombreuses, rendant l'intégration cauchemardesque.

Si la fonctionnalité est relativement simple et que le développement ne prend pas beaucoup de temps, vous pouvez adopter une solution simple, qui consiste à garder une branche distincte, que vous intégrerez lorsque le développement sera fini. Dans l'assistant de fusion, ce devrait n'être qu'un simple Fusionner une plage de révisions, la plage de révisions couvrant la période de développement de la branche.

Dans le cas où la fonctionnalité prend plus de temps et que vous avez besoin de prendre en compte les évolutions du trunk, alors vous devez garder votre branche synchronisée. Cela signifie simplement que vous allez fusionner de temps en temps les évolutions du trunk dans votre branche, de manière à ce que votre branche contienne toutes les modifications du trunk en plus de la nouvelle fonctionnalité. Le processus de synchronisation utilise la commande Fusionner une plage de révisions. Quand le développement de la fonctionnalité est achevé vous pouvez alors fusionner la branche dans le trunk en utilisant soit Réintégrer une branche soit Fusionner deux arborescences.

Une autre façon (rapide) de fusionner tous les changements du trunk dans la branche de la fonctionnalité est d'utiliser la commande TortoiseSVN → Fusionner tout... dans le menu contextuel étendu (gardez appuyée la touche Maj en faisant un clic droit sur le fichier).

Figure 4.60. La boîte de dialogue Fusionner tout

Cette boîte de dialogue est très simple. Tout ce que vous avez à faire est de positionner les options pour la fusion, comme décrit dans la section intitulée « Options de fusion ». TortoiseSVN s'occupe automatiquement du reste avec le suivi de fusion.

Par défaut, rien n'est verrouillé et quiconque a un accès en livraison peut livrer des modifications de n'importe quel fichier à tout moment. Les autres mettront à jour leurs copies de travail périodiquement et les modifications du dépôt seront fusionnées avec les modifications locales.

Si vous obtenez un verrou sur un fichier, alors vous seul pouvez livrer ce fichier. Les livraisons des autres utilisateurs seront bloquées jusqu'à ce que vous retiriez le verrou. Un fichier verrouillé ne peut être modifié d'aucune façon dans le dépôt, il ne peut donc pas non plus être supprimé ou renommé, sauf par le propriétaire du verrou.

Toutefois, les autres utilisateurs ne sauront pas nécessairement que vous avez posé un verrou. À moins qu'ils ne vérifient le verrouillage régulièrement, ils ne le découvriront que lorsque leur livraison échouera, ce qui n'est pas très utile dans la plupart des cas. Pour rendre la gestion des verrous plus facile, il existe une nouvelle propriété Subversion svn:needs-lock. Quand cette propriété est définie (avec n'importe quelle valeur) sur un fichier, chaque fois que le fichier est extrait ou mis à jour, la copie locale est mise en lecture seule à moins que cette copie de travail ne détienne un verrou pour le fichier. Cela agit comme un avertissement de ne pas éditer ce fichier à moins que vous n'ayez d'abord posé un verrou. Les fichiers qui sont versionnés et en lecture seule sont identifiés par une coloration spéciale dans TortoiseSVN, pour indiquer que vous devez poser un verrou avant l'édition.

Les verrous sont enregistrés par emplacement de copie de travail et par propriétaire. Si vous avez plusieurs copies de travail (à la maison, au travail) alors vous ne pouvez détenir un verrou que dans une de ces copies de travail.

Si l'un de vos collègues pose un verrou et part ensuite en vacances sans le retirer, que faites-vous ? Subversion fournit un moyen de forcer les verrous. Retirer un verrou détenu par quelqu'un d'autre s'appelle casser le verrou et prendre de force un verrou déjà détenu par quelqu'un d'autre s'appelle voler le verrou. Naturellement, ce ne sont pas des choses que vous devriez faire à la légère, si vous voulez rester en bons termes avec vos collègues.

Les verrous sont enregistrés dans le dépôt et un jeton de verrouillage est créé dans votre copie de travail locale. S'il y a une incohérence, par exemple si quelqu'un d'autre a cassé le verrou, le jeton de verrouillage local devient invalide. Le dépôt est toujours la référence absolue.

Sélectionnez les fichiers de votre copie de travail pour lesquels vous voulez un verrou, puis sélectionnez la commande TortoiseSVN → Obtenir un verrou....

Figure 4.61. La boîte de dialogue Verrouiller

Une boîte de dialogue apparaît, vous permettant de saisir un commentaire, pour que les autres puissent voir pourquoi vous avez verrouillé le fichier. Le commentaire est facultatif et actuellement utilisé avec les seuls dépôts basés sur Svnserve. Si (et seulement si) vous devez voler le verrou de quelqu'un d'autre, cochez la case Voler les verrous, puis cliquez sur OK.

Vous pouvez positionner la propriété de projet tsvn:logtemplatelock pour fournir un modèle de message de verrouillage à compléter par les utilisateurs. Voyez la section intitulée « Configuration des projets » pour des instructions sur comment positionner les propriétés.

Si vous sélectionnez un dossier et utilisez ensuite TortoiseSVN → Obtenir un verrou... la boîte de dialogue Verrouiller s'ouvrira avec tous les fichiers de tous les sous-dossiers sélectionnés pour être verrouillés. C'est la bonne manière de faire si vous voulez vraiment verrouiller une arborescence complète, cependant vous pourriez devenir très impopulaire auprès de vos collègues si vous les empêchez d'accéder au projet. À utiliser avec parcimonie...

Pour vous assurer de ne pas oublier de retirer un verrou dont vous n'avez plus besoin, les fichiers verrouillés sont affichés dans la boîte de dialogue de livraison et sélectionnés par défaut. Si vous continuez la livraison, les verrous que vous détenez sur les fichiers sélectionnés sont supprimés, même si les fichiers n'ont pas été modifiés. Si vous ne voulez pas retirer les verrous de certains fichiers, vous pouvez les décocher (s'ils ne sont pas modifiés). Si vous voulez garder un verrou sur un fichier que vous avez modifié, vous devez activer la case à cocher Garder les verrous avant de livrer vos changements.

Pour retirer un verrou manuellement, sélectionnez les fichiers de votre copie de travail dont vous voulez retirer les verrous, choisissez ensuite la commande TortoiseSVN → Retirer un verrou Il n'y a rien d'autre préciser, et TortoiseSVN va communiquer avec le dépôt et retirer les verrous. Vous pouvez aussi utiliser cette commande sur un dossier pour retirer tous les verrous récursivement.

Figure 4.62. La boîte de dialogue Vérifier les modifications

Pour voir quels verrous les autres et vous détenez, vous pouvez utiliser TortoiseSVN → Vérifier les modifications.... Les jetons de verrouillage détenus localement s'afficheront immédiatement. Pour vérifier les verrous détenus par les autres (et voir si l'un de vos verrous est cassé ou volé) vous devez cliquer sur Vérifier le dépôt.

À partir du menu contextuel accessible ici, vous pouvez aussi bien obtenir et retirer des verrous, que casser et voler des verrous détenus par d'autres.

Comme mentionné ci-dessus, la façon la plus efficace d'utiliser le verrouillage est de mettre la propriété svn:needs-lock sur les fichiers. Référez-vous à la section intitulée « Configuration des projets » pour les instructions sur le mode d'activation des propriétés. Les fichiers avec cette propriété activée seront toujours extraits et mis à jour avec l'attribut Lecture seule activé à moins que votre copie de travaill ne détienne un verrou.

Pour vous le rappeler, TortoiseSVN utilise une coloration spéciale pour l'indiquer.

Si vous appliquez une politique où tout fichier doit être verrouillé, vous pouvez trouver alors plus facile d'utiliser la fonctionnalité auto-props de Subversion pour activer la propriété automatiquement à chaque fois vous ajoutez de nouveaux fichiers. Lisez la section intitulée « Configuration de TortoiseSVN » pour plus d'informations.

Quand vous créez un nouveau dépôt avec Subversion 1.2 ou supérieur, quatre modèles de hooks sont créés dans le répertoire hooks du dépôt. Ceux-ci sont appelés avant et après l'obtention d'un verrou et avant et après le retrait d'un verrou.

C'est une bonne idée d'installer un script hook post-lock et post-unlock sur le serveur qui envoie un e-mail indiquant que le fichier a été verrouillé. Avec une tel script d'installé, tous vos utilisateurs peuvent être informés si quelqu'un verrouille/déverrouille un fichier. Vous pouvez trouver un script hook d'exemple hooks/post-lock.tmpl dans le dossier de votre dépôt.

Vous pourriez aussi utiliser des hooks pour ne pas permettre la casse ou le vol de verrous, ou peut-être les limiter à un administrateur nommé. Ou peut-être vous voulez envoyer un email au propriétaire quand l'un de ses verrous est cassé ou volé.

Lisez la section intitulée « Scripts hook côté serveur » pour en savoir plus.

D'abord vous devez faire et tester vos changements. Alors au lieu d'utiliser TortoiseSVN → Livrer... sur le dossier parent, vous sélectionnez TortoiseSVN → Créer un patch...

Figure 4.63. La boîte de dialogue Créer un patch

Vous pouvez maintenant choisir les fichiers que vous voulez inclure dans le patch, comme vous le feriez avec une livraison complète. Cela produira un unique fichier contenant un résumé de tous les changements que vous avez faits aux fichiers sélectionnés depuis la dernière mise à jour du dépôt.

Les colonnes dans cette boîte de dialogue peuvent être personnalisées de la même manière que les colonnes dans la boîte de dialogue Vérifier les modifications. Lisez la section intitulée « Statut local et distant » pour plus de détails.

En cliquant sur le bouton Options, vous pouvez spécifier comment le patch est créé. Par exemple, vous pouvez spécifier que les changements de caractères de fin de ligne ou d'espacement ne sont pas inclus dans le fichier de patch final.

Vous pouvez produire des patches séparés contenant des changements sur des jeux différents de fichiers. Bien sûr, si vous créez un fichier patch, faites d'autres changements dans les mêmes fichiers et créez ensuite un autre patch, le deuxième fichier patch inclura les deux jeux de changements.

Sauvegardez juste le fichier en utilisant un nom de fichier de votre choix. Les patches peuvent avoir l'extension de votre choix, mais selon la convention ils devraient utiliser les extensions .patch ou .diff. Vous êtes maintenant prêt à soumettre votre patch.

Vous pouvez aussi sauvegarder le patch dans le presse-papier plutôt que dans un fichier. Cela permet, par exemple, de le coller dans un mail afin de le transmettre à d'autres personnes pour une revue. Ou alors, si vous avez deux copies de travail sur une machine et que vous vouliez reporter des changements de l'une à l'autre, copier le patch dans le presse-papier est un moyen commode pour le faire.

Si vous préférez, vous pouvez créer un fichier de patch depuis les boîtes de dialogue Livrer ou Vérifier les modifications. Sélectionnez les fichiers et utilisez l'élément du menu contextuel pour créer un patch à partir de ces fichiers. Si vous voulez voir la boîte de dialogue Options, vous devez garder la touche Maj appuyée en faisant un clic droit.

Les fichiers patch sont appliqués sur votre copie de travail. Cela doit être fait au même niveau de dossier qui a été utilisé pour créer le patch. Si vous n'êtes pas sûr duquel il s'agit, regardez simplement la première ligne du fichier de patch. Par exemple, si le premier fichier sur lequel vous avez travaillé était doc/source/francais/chapitre1.xml et que la première ligne dans le fichier de patch est Index: francais/chapitre1.xml alors vous devez appliquer le patch sur le dossier doc/source/. Cependant, du moment que vous êtes dans la bonne copie de travail, si vous choisissez le mauvais niveau de dossier, TSVN le remarquera et suggérera le niveau correct.

Pour appliquer un patch à votre copie de travail, vous devez avoir au moins l'accès en lecture pour le dépôt. La raison à cela est que le programme de fusion doit faire référence aux changements de la révision avec laquelle ils ont été faits par le développeur distant.

Depuis le menu contextuel de ce dossier, cliquez sur TortoiseSVN → Appliquer le patch... Cela affichera une boîte de dialogue Ouvrir un fichier vous permettant de choisir le fichier patch à appliquer. Par défaut, seuls les fichiers .patch ou .diff sont affichés, mais vous pouvez opter pour "Tous les fichiers ". Si vous avez précédemment sauvegardé le patch dans le presse-papier, vous pouvez utiliser le bouton Ouvrir depuis le presse-papier dans le dialogue d'ouverture de fichiers. Notez que cette option est visible dans le cas où vous avez sauvegardé votre patch dans le presse-papier via le menu TortoiseSVN → Créer un patch.... La copie d'un patch du presse-papier vers une autre application ne fera pas appaître ce bouton.

Alternativement, si le fichier patch a une extension .patch ou .diff, vous pouvez faire un clic droit dessus directement et sélectionnez TortoiseSVN → Appliquer un patch.... Dans ce cas, vous serez invité à entrer un emplacement de copie de travail.

Ces deux méthodes offrent juste des façons différentes de faire la même chose. Avec la première méthode, vous choisissez la CdT et naviguez jusqu'au patch. Avec la deuxième, vous choisissez le patch et naviguez jusqu'à la CdT.

Une fois que vous avez sélectionné le fichier patch et l'emplacement de la copie de travail, TortoiseMerge se lance pour fusionner les changements du fichier patch avec votre copie de travail. Une petite fenêtre liste les fichiers qui ont été changés. Double-cliquez sur chacun à son tour, passez en revue les changements et sauvegardez les fichiers fusionnés.

Le patch du développeur distant a maintenant été appliqué à votre copie de travail, donc vous devez livrer pour permettre à tous les autres d'avoir accès aux changements depuis le dépôt.

Figure 4.64. La boîte de dialogue Annoter

Si vous n'êtes pas intéressé par les changements des révisions précédentes, vous pouvez définir la révision d'où l'annotation devrait commencer. Mettez ce champ à 1 si vous voulez l'annotation pour toutes les révisions.

Par défaut, le fichier d'annotation est visualisé avec TortoiseBlame, qui surligne les différentes révisions pour le rendre plus facile à lire. Si vous voulez imprimer ou éditer le fichier d'annotation, cochez Utiliser la visionneuse texte pour voir les annotations.

Vous pouvez spécifier la manière de gérer les changements de caractères de fin de ligne et d'espacement. Ces options sont décrites dans la section intitulée « Options de fins de ligne et d'espacement ». Par défaut, toutes les modifications de caractères de fin de ligne et d'espacement sont considérés comme des changements à part entière, mais si vous souhaitez ignorer les changements d'indentation et trouver l'auteur original, vous pouvez sélectionner l'option appropriée ici.

Vous pouvez également inclure les informations de fusion si vous le souhaitez, bien que cette option puisse prendre nettement plus longtemps à récupérer depuis le serveur. Quand les lignes sont fusionnées depuis une autre source, l'information d'annotation montre la révision à laquelle le changement a été fait dans la source originale ainsi que la révision à laquelle il a été fusionné dans ce fichier.

Une fois que vous appuyez sur OK, TortoiseSVN commence à récupérer les données pour créer le fichier d'annotation. Une fois que le processus d'annotation est terminé, le résultat est écrit dans un fichier temporaire et vous pouvez visualiser les résultats.

Figure 4.65. TortoiseBlame

TortoiseBlame, qui est inclus avec TortoiseSVN, rend le fichier d'annotation plus facile à lire. Quand vous survolez avec la souris une ligne dans la colonne de renseignements de l'annotation, toutes les lignes avec la même révision sont affichées avec un fond plus sombre. Les lignes d'autres révisions qui ont été changées par le même auteur sont affichées avec un fond clair. La coloration peut ne pas fonctionner aussi clairement si vous avez votre affichage en mode 256 couleurs.

Si vous faites un clic gauche sur une ligne, toutes les lignes avec la même révision sont mises en évidence et les lignes d'autres révisions du même auteur sont mises en évidence dans une couleur plus claire. Cette accentuation est figée, vous permettant de déplacer la souris sans perdre les points en évidence. Cliquez sur cette révision de nouveau pour arrêter l'accentuation.

Les commentaires de révision (commentaire du journal) sont affichés dans une info-bulle à chaque fois que la souris survole la colonne d'information de l'annotation. Si vous voulez copier le commentaire de cette révision, utilisez le menu contextuel qui apparaît quand vous faites un clic droit sur la colonne d'information de l'annotation.

Vous pouvez faire des recherches dans le rapport d'annotation en utilisant Éditer → Rechercher.... Cela vous permet de chercher des numéros de révision, des auteurs et le contenu du fichier lui-même. Les commentaires ne sont pas inclus dans la recherche — vous devez utiliser la boîte de dialogue du journal pour faire une recherche dedans.

Vous pouvez aussi aller à une ligne particulière en utilisant Editer → Aller à la ligne....

Lorsque la souris survole la colonne annotation, un menu contextuel s'affiche vous permettant de comparer les révision et de consulter l'historique, en prenant comme référence le numéro de ligne sous le curseur de la souris. Menu contextuel → Annoter la révision précédente crée une annotation sur ce même fichier, mais en utilisant la révision précédente comme limite supérieure. Cela vous donne le rapport d'annotation du fichier dans l'état où il était juste avant que la ligne que vous survolez soit modifiée pour la dernière fois. Menu contextuel → Montrer les modifications démarre votre visionneuse de différences, vous montrant ce qui a changé à la révision référencée. Menu contextuel → Montrer les commentaires affiche la boîte de dialogue du journal des révisions, en commençant par la révision référencée.

Si vous souhaitez un meilleur indicateur visuel de l'emplacement des modifications les plus récentes et les plus anciennes, sélectionnez Voir → Colorer l'âge des lignes. Cette option utilisera un gradient de couleur pour afficher les lignes les plus récentes en rouge et les plus anciennes en bleu. La coloration par défaut est assez légère, mais vous pouvez la modifier en utilisant les préférences de TortoiseBlame.

Si vous utilisez le suivi de fusion et que vous avez demandé les informations de fusion en lançant l'annotation, les lignes fusionnées sont affichées d'une façon légèrement différente. Quand une ligne a changé à la suite d'une fusion depuis un autre chemin, TortoiseBlame affichera la révision et l'auteur du dernier changement dans le fichier original plutôt que la révision où la fusion a eu lieu. Ces lignes sont indiquées en affichant la révision et l'auteur en italique. La révision où la fusion a eu lieu est affichée séparément dans l'infobulle quand la souris survole les colonnes d'information d'annotation. Si vous ne voulez pas que les lignes fusionnées soient affichées de cette façon, décochez la case Inclure les informations de fusion au moment de commencer l'annotation.

Si vous voulez voir les chemins concernés par la fusion, sélectionnez Voir → Fusionner les chemins. Cela affiche le chemin où la ligne a été modifiée pour la dernière fois, à l'exclusion des changements qui résultent d'une fusion.

La révision affichée dans l'information d'annotation représente la dernière révision où le contenu de cette ligne a changé. Si le fichier a été créé en copiant un autre fichier, alors, jusqu'à ce que vous changiez une ligne, sa révision d'annotation affichera le dernier changement dans le fichier source original, pas la révision où la copie a été effectuée. Cela s'applique également aux chemins affichés avec les informations de fusion. Le chemin affiche l'emplacement du dépôt où le dernier changement a été fait sur cette ligne.

On peut accéder aux paramètres de TortoiseBlame en sélectionnant TortoiseSVN → Paramètres... dans l'onglet TortoiseBlame. Voir la section intitulée « Configuration de TortoiseBlame ».

Une des limitations du rapport d'annotation est qu'il ne montre que le fichier tel qu'il était dans une révision donnée, et la dernière personne à changer chaque ligne. Parfois vous voulez savoir ce qui a été changé, ainsi que qui l'a changé. Si vous faites un clic droit sur une ligne dans TortoiseBlame, vous avez un élément de menu contextuel pour afficher les changements effectués dans cette révision. Mais si voulez voir les changements et les informations d'annotation en même temps, alors vous avez besoin d'une combinaison des rapports de comparaison et d'annotation.

La boîte de dialogue du journal de révision inclut plusieurs options vous permettant de faire cela.

Chaque nœud du graphe représente une révision dans le dépôt dans laquelle quelque chose a changé dans l'arborescence que vous examinez. Les différents types de nœuds peuvent être distingués par leur forme et leur couleur. Les formes sont fixes, mais les couleurs peuvent être définies à l'aide de TortoiseSVN → Paramètres

Notez que par défaut le graphique ne montre que les points auxquels des éléments ont été ajoutés, copiés ou supprimés. Afficher chaque révision d'un projet pourrait produire un graphique très grand pour des cas non triviaux. Si vous voulez vraiment voir toutes les révisions pour lesquelles des modifications ont été apportées, il existe une option pour ce faire dans le menu Affichage et sur la barre d'outils.

L'affichage par défaut (sans regroupement) place les nœuds de telle sorte que leur position verticale reflète l'ordre strict de révision, afin que vous ayez un repère visuel pour l'ordre dans lequel les choses ont été faites. Lorsque deux nœuds sont dans la même colonne, l'ordre est très évident. Lorsque deux nœuds sont dans des colonnes voisines, le décalage est beaucoup plus faible car il n'est pas nécessaire d'empêcher les nœuds de se chevaucher, et en conséquence l'ordre est un peu moins évident. Ces optimisations sont nécessaires pour que les graphiques complexes conservent une taille raisonnable. Veuillez noter que cette organisation utilise le bord du nœud sur l'ancien côté comme une référence, c'est à dire le bord inférieur du nœud lorsque le graphique est représenté avec le plus ancien nœud en bas. Le bord de référence est important, car les formes des nœuds n'ont pas toutes la même hauteur.

Parce qu'un graphique de révision est souvent très complexe, il existe un certain nombre de caractéristiques qui peuvent être utilisées pour adapter la façon dont vous souhaitez le voir. Celles-ci sont disponibles dans le menu Voir et à partir de la barre d'outils.

Pour rendre plus facile la navigation dans un large graphe, utilisez la fenêtre Aperçu. Cela montre le graphique entier dans une petite fenêtre, avec la partie actuellement affichée en surbrillance. Vous pouvez faire glisser la zone en surbrillance pour changer la région affichée.

La date de révision, l'auteur et les commentaires sont affichés dans une info-bulle chaque fois que la souris survole une boîte de révision.

Si vous sélectionnez deux révisions (faites un clic gauche avec Ctrl), vous pouvez utiliser le menu contextuel pour afficher les différences entre ces révisions. Vous pouvez vouloir afficher les différences comme aux points de création de branche, mais le plus souvent vous voudrez afficher les différences aux points de fin de branche, c'est-à-dire à la révision HEAD.

Vous pouvez voir les différences avec un fichier de différences unifiées, qui montre toutes les différences dans un seul fichier avec un contexte minimal. Si vous optez pour Menu contextuel → Comparer les révisions, vous vous retrouvez avec une liste des fichiers modifiés. Double-cliquez sur un nom de fichier pour aller chercher les deux révisions du fichier et les comparer en utilisant l'outil de comparaison visuel.

Si vous faites un clic droit sur une révision, vous pouvez utiliser Menu contextuel → Voir le journal pour voir l'historique.

Vous pouvez également fusionner les modifications dans la (les) révision(s) sélectionnée(s) dans une autre copie de travail. Une boîte de dialogue de sélection de dossier vous permet de choisir la copie de travail vers laquelle fusionner, mais après cela il n'y a pas de demande de confirmation, ni possibilité de mener un test de fusion. C'est une bonne idée de fusionner dans une copie de travail non modifiée afin que vous puissiez annuler les modifications si elles ne fonctionnent pas ! Cette fonctionnalité est utile si vous souhaitez fusionner les versions sélectionnées d'une branche à l'autre.

Si vous voulez vérifier s'il y a de nouvelles informations sur le serveur, il vous suffit de rafraîchir la vue en utilisant F5. Si vous utilisez le cache du journal (activé par défaut), cela va vérifier les livraisons les plus récentes dans le dépôt et récupérer seulement les nouvelles. Si le cache du journal était en mode hors connexion, cela va aussi tenter de se reconnecter.

Si vous utilisez le cache du journal et que vous pensez que le contenu du message ou l'auteur a pu changer, vous devriez utiliser la boîte de dialogue du journal pour actualiser les messages dont vous avez besoin. Puisque le graphique des révisions se base sur la racine du dépôt, nous aurions à invalider intégralement le cache du journal, et le remplir à nouveau pourrait prendre un temps très long.

Il peut être difficile de naviguer dans un grand arbre et parfois vous souhaiterez en cacher certaines parties, ou le décomposer en une forêt de plus petits arbres. Si vous passez la souris sur le point où un lien entre ou sort d'un nœud, vous verrez un ou plusieurs boutons popup qui vous permettent de le faire.

Cliquez sur le bouton moins pour réduire la sous-arborescence.

Cliquez sur le bouton plus pour développer une sous-arborescence réduite. Quand une arborescence a été réduite, ce bouton reste visible pour signaler la sous-arborescence cachée.

Cliquez sur le bouton croix pour séparer la sous-arborescence et l'afficher comme une arborescence séparée.

Cliquez sur le bouton cercle pour ré-attacher une sous-arborescence préalablement séparée. Quand une arborescence a été séparée, ce bouton reste visible pour signaler qu'il y a une sous-arborescence séparée.

Cliquez sur l'arrière-plan du graphique pour le menu contextuel principal, qui offre des options pour Tout développer et Tout replier. Si aucune branche n'a été repliée ou séparée, le menu contextuel ne sera pas montré.

Parfois vous avez une copie de travail que vous voulez faire revenir à l'état de dossier normal sans le répertoire .svn. Tout ce que vous avez à faire est de supprimer le répertoire .svn de la racine de la copie de travail.

Une alternative possible est d'exporter le dossier vers lui-même. Dans l'explorateur Windows, faites glisser avec le bouton droit le dossier racine de la copie de travail depuis le panneau de liste des fichiers vers lui-même dans le panneau d'arborescence des dossiers. TortoiseSVN détecte ce cas spécial et vous demande si vous voulez déversionner la copie de travail. Si vous répondez oui, le répertoire de contrôle sera supprimé et vous aurez une arborescence non versionnée.

Vous pouvez intégrer le traqueur de bugs de votre choix dans TortoiseSVN. Pour ce faire, vous devez définir quelques propriétés, qui commencent par bugtraq:. Elles doivent être définies sur les dossiers : (la section intitulée « Configuration des projets »)

Figure 4.70. La boîte de dialogue des propriétés bugtraq

Quand vous éditez une propriété bugtraq, un éditeur de propriétés spécial est utilisé pour faciliter la saisie de valeurs appropriées.

Il y a deux façons d'intégrer TortoiseSVN avec les gestionnaires d'incidents. L'une est basée sur des chaînes simples, l'autre sur les expressions régulières. Les propriétés utilisées par les deux approches sont :

Si les deux propriétés bugtraq:message et bugtraq:logregex sont définies, logregex a la priorité.

Certaines propriétés tsvn: exigent une valeur true/false. TortoiseSVN comprend aussi yes comme synonyme de true et no comme synonyme de false.

Lorsque vous ajoutez un nouveau sous-dossier à une copie de travail via TortoiseSVN, toutes les propriétés de projet du dossier parent seront automatiquement ajoutées à ce nouveau dossier fils.

L'intégration de suivi d'incidents n'est pas limitée à TortoiseSVN ; elle peut être utilisée avec n'importe quel client Subversion. Pour plus d'informations, lisez la spécification de l'intégration de suivi d'incidents dans le dépôt des sources de TortoiseSVN. (La la section intitulée « Licence » détaille comment accéder au dépôt.)

La section précédente porte sur l'ajout d'information concernant les incidents dans des messages de log. Mais que faire si vous avez besoin d'obtenir des informations du gestionnaire d'incidents ? La boîte de dialogue de révision possède une interface COM qui permet l'intégration d'un programme externe qui peut dialoguer avec votre logiciel de gestion. Typiquement, vous voudrez peut-être interroger le gestionnaire pour obtenir la liste des incidents ouverts qui vous sont assignés, de sorte que vous pouvez choisir les incidents qui sont abordées dans cette livraison.

Toute interface de ce type est évidemment extrêmement spécifique à votre système de gestion d'incidents, ce qui fait que nous ne pouvons pas en fournir, et décrire comment créer un tel logiciel dépasse le cadre de ce manuel. La définition d'interface et les exemples de plugin en C# et C++/ATL sont disponibles dans le dossier contrib du dépôt TortoiseSVN. (La la section intitulée « Licence » détaille comment accéder au dépôt.) Un résumé de l'API est également fourni au Chapitre 7, IBugtraqProvider interface. Un autre exemple (fonctionnel) de plugin en C# est Gurtle, qui implémente l'interface COM requise pour interagir avec le gestionnaire d'incidents de Google Code.

À titre d'exemple, supposons que votre administrateur système vous a fourni un plugin de gestionnaire d'incidents que vous avez installé, et que vous avez paramétré certaines de vos copies de travail pour utiliser le plugin dans la boîte de configuration de TortoiseSVN. Lorsque vous ouvrez la boîte de dialogue de livraison à partir d'une copie de travail à laquelle le plugin a été attribué, vous pourrez voir un nouveau bouton en haut de la boîte de dialogue.

Figure 4.71. Exemple de fenêtre de gestionnaire d'incidents

Dans cet exemple, vous pouvez sélectionner un ou plusieurs incidents en suspens. Le plugin peut alors générer du texte spécialement mis en forme qu'il ajoute à votre message de log.