De temps en temps, vous aurez un conflit au moment de mettre à jour/fusionner vos fichiers avec le dépôt ou lorsque vous migrerez votre copie de travail vers une autre URL. Il y a deux sortes de conflits :
Un conflit de fichier se produit si deux (ou plus) développeurs changent les mêmes lignes d'un fichier.
Un conflit d'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é.
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 :
C'est votre fichier comme il a existé dans votre copie de travail avant que vous mettiez à jour votre copie de travail - c'est-à-dire sans marqueurs de conflit. Ce fichier a vos derniers changements et rien d'autre.
C'est le fichier qui était la révision de BASE avant que vous mettiez à jour votre copie de travail. C'est-à-dire le fichier que vous avez extrait avant de faire votre dernière édition.
C'est le fichier que votre client de Subversion venait de recevoir du serveur quand vous avez mis à jour votre copie de travail. Ce fichier correspond à la révision de tête du dépôt.
Vous pouvez soit lancer un outil externe de fusion ou un éditeur de conflits avec → , 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 → 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 → 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.
Le développeur A modifie toto.c et le livre sur le dépôt.
Dans le même temps, le développeur B a renommé toto.c en titi.c dans sa copie de travail, ou simplement supprimé toto.c ou son dossier parent.
Une mise à jour de la copie de travail du développeur B mène à un conflit d'arborescence :
toto.c a été supprimé de la copie de travail, mais est marqué comme étant en conflit d'arborescence.
Si le conflit provient d'un renommage plutôt que d'une suppression, alors titi.c est marqué comme ajouté, mais ne contient pas les modifications du développeur A.
Le développeur B doit maintenant choisir s'il veut conserver les modifications du développeur A. Dans le cas d'un renommage de fichier, il peut fusionner les modifications de toto.c dans le fichier renommé titi.c. Pour de simples suppressions de fichier ou de répertoire, il peut choisir de garder l'élément avec les modifications du développeur A et annuler la suppression. Ou bien, en se contentant de marquer le conflit comme étant résolu sans rien faire d'autre, il peut annuler les modifications du développeur A.
La boîte de dialogue d'édition de conflit propose de fusionner les changements si elle parvient à trouver le fichier original qui a été renommé en titi.c. S'il y a plusieurs fichiers qui sont des points de départ potentiels, alors elle montre un bouton pour chacun de ces fichiers pour vous permettre de choisir le bon.
Le développeur A renomme toto.c en titi.c et livre les modifications dans le dépôt.
Le développeur B modifie toto.c dans sa copie de travail.
Ou dans le cas d'un renommage de dossier...
Le développeur A renomme le dossier parent DossierToto en DossierTiti et le livre dans le dépôt.
Le développeur B modifie toto.c dans sa copie de travail.
Une mise à jour de la copie de travail du développeur B mène à un conflit d'arborescence. Pour un simple conflit de fichier :
titi.c est ajouté dans la copie de travail comme un fichier ordinaire.
toto.c est marqué comme ayant été ajouté (avec historique) et présente un conflit d'arborescence.
Pour un conflit de dossier :
DossierTiti est ajouté dans la copie de travail comme un dossier ordinaire.
DossierToto est marqué comme ayant été ajouté (avec historique) et présente un conflit d'arborescence.
Foo.c est marqué comme modifié.
Le développeur B doit à présent décider s'il veut garder la réorganisation du développeur A et fusionner ses changements dans le fichier correspondant dans la nouvelle architecture, ou simplement annuler les modifications de A et garder le fichier local.
Pour fusionner ses changements locaux avec la réorganisation, le développeur B doit d'abord déterminer le nouveau nom et le nouvel emplacement du fichier en conflit toto.c dans le dépôt. Cela peut se faire avec la boîte de dialogue de journal. Ensuite, il faut utiliser le bouton qui indique le bon fichier source pour résoudre le conflit.
Si le développeur B décide que les changements de A étaient faux, alors il doit choisir le bouton Marquer comme résolu dans la boîte de dialogue d'édition de conflit. Cela marque le fichier ou le dossier en conflit comme résolu, mais les changements du développeur A doivent être supprimés à la main. Là aussi, la boîte de dialogue de journal aide à retrouver ce qui a été déplacé.
Le développeur A renomme toto.c en titi.c et livre les modifications dans le dépôt.
Le développeur B renomme toto.c en tata.c.
Une mise à jour de la copie de travail du développeur B mène à un conflit d'arborescence :
tata.c est marqué comme ayant été ajouté avec historique.
titi.c est ajouté dans la copie de travail avec le statut 'normal'.
toto.c est marqué comme étant supprimé et présente un conflit d'arborescence.
Pour résoudre ce conflit, le développeur B doit déterminer le nouveau nom et le nouvel emplacement du fichier en conflit toto.c dans le dépôt. Cela peut se faire avec la boîte de dialogue de journal.
Ensuite, le développeur B doit décider lequel des nouveaux noms de toto.cgarder - celui du développeur A ou celui issu du renommage qu'il a lui-même effectué.
Une fois que le développeur B a résolu manuellement le conflit, le conflit d'arborescence doit être marqué comme résolu grâce au bouton approprié dans la boîte de dialogue d'édition de conflit.
Le développeur A, qui travaille sur le tronc, modifie toto.c et le livre dans le dépôt.
Le développeur B, qui travaille sur une branche, renomme toto.c en titi.c et le livre dans le dépôt
Une fusion des modifications du tronc du développeur A dans la branche de copie de travail du développeur B conduit à un conflit d'arborescence :
titi.c est déjà dans la copie de travail avec le statut 'normal'.
toto.c est marqué comme manquant avec un conflit d'arborescence.
Pour résoudre ce conflit, le développeur B doit marquer le fichier comme résolu dans la boîte de dialogue d'édition de conflit, ce qui le retirera de la liste des conflits. Le développeur B doit alors décider s'il faut copier le fichier manquant toto.c depuis le dépôt, ou fusionner les changements du développeur A toto.c avec le fichier renommé titi.c, ou encore ignorer les changements en marquant le conflit comme résolu sans rien faire d'autre.
Notez que si vous copiez le fichier manquant depuis le dépôt et que vous le marquez comme résolu, votre copie sera de nouveau retirée. Vous devez résoudre d'abord le conflit.
Le développeur A, qui travaille sur le tronc, renomme toto.c en titi.c et le livre dans le dépôt.
Le développeur B, qui travaille sur une branche, modifie le fichier toto.c et le livre dans le dépôt.
Le développeur A, qui travaille sur le tronc, renomme le dossier parent DossierToto en DossierTiti et le livre dans le dépôt.
Le développeur B, qui travaille sur une branche, modifie toto.c dans sa copie de travail.
Une fusion des modifications du tronc du développeur A dans la branche de copie de travail du développeur B conduit à un conflit d'arborescence :
titi.c est marqué comme étant ajouté.
toto.c est marqué comme ayant été modifié et présente un conflit d'arborescence.
Le développeur B doit à présent décider s'il veut garder la réorganisation du développeur A et fusionner ses changements dans le fichier correspondant dans la nouvelle architecture, ou simplement annuler les modifications de A et garder le fichier local.
Pour fusionner ses changements locaux avec la réorganisation, le développeur B doit d'abord déterminer le nouveau nom et le nouvel emplacement du fichier en conflit toto.c dans le dépôt. Cela peut se faire avec la boîte de dialogue de journal pour la source de la fusion. L'éditeur de conflit ne montre que le journal de la copie de travail, car il ne sait pas quel chemin a été utilisé dans la fusion, donc vous devez trouver cela vous-même. Les changements doivent alors être fusionnés à la main, car il n'y a actuellement aucune façon d'automatiser ou même de simplifier le processus. Une fois que les changements ont été portés, le chemin en conflit est redondant et peut être supprimé.
Si le développeur B décide que les changements de A étaient faux, alors il doit utiliser le bouton Marquer comme résolu dans la boîte de dialogue d'éditeur de conflit. Cela marque le fichier ou le dossier en conflit comme résolu, mais les changements du développeur A doivent être supprimés à la main. Là encore, la boîte de dialogue de journal pour la source de la fusion aide à retrouver ce qui a été déplacé.
Le développeur A, qui travaille sur le tronc, renomme toto.c en titi.c et le livre dans le dépôt.
Le développeur B, qui travaille sur une branche, renomme toto.c en tata.c et le livre dans le dépôt.
Une fusion des modifications du tronc du développeur A dans la branche de copie de travail du développeur B conduit à un conflit d'arborescence :
tata.c est marqué comme étant dans un état normal (non modifé).
titi.c est marqué comme ajouté avec son historique.
toto.c est marqué comme manquant et présente un conflit d'arborescence.
Pour résoudre ce conflit, le développeur B doit déterminer le nouveau nom et le nouvel emplacement du fichier en conflit toto.c dans le dépôt. Cela peut se faire avec la boîte de dialogue de journal pour la source de la fusion.
Ensuite, le développeur B doit décider lequel des nouveaux noms de toto.cgarder - celui du développeur A ou celui issu du renommage qu'il a lui-même effectué.
Une fois que le développeur B a résolu manuellement le conflit, le conflit d'arborescence doit être marqué comme résolu grâce au bouton approprié dans la boîte de dialogue d'édition de conflit.
Il y a d'autres cas qui sont considérés comme des conflits d'arborescence tout simplement parce que le conflit concerne un dossier plutôt qu'un fichier. Par exemple, si vous ajoutez un dossier qui porte le même nom à la fois dans le tronc et dans une branche puis que vous essayez de fusionner, vous obtiendrez un conflit d'arborescence. Si vous souhaitez conserver le dossier dans la fusion cible, marquez simplement le conflit comme résolu. Si vous souhaitez utiliser celui de la source, alors vous devez d'abord utiliser la commande SVN Supprimer sur celui de la cible, puis exécuter à nouveau la fusion. Si vous avez besoin de quelque chose de plus complexe, vous devrez le résoudre manuellement.