Résoudre des conflits

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:

Conflit de fichier

Un conflit sur un fichier arrive si deux (ou plus) développeurs changent les mêmes lignes d'un fichier.

Conflits dans l'arborescence

Un conflit dans l'arborescence arrive quand un développeur déplace/renomme/supprime un fichier ou un dossier, qu'un autre développeur a aussi déplacé/renommé/supprimé voire juste modifié.

Conflit de fichiers

A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. The conflicting area in a text file is marked like this:

<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision
      

Also, for every conflicted file Subversion places three additional files in your directory:

nom_du_fichier.ext.mine

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.

nom_du_fichier.ext.rOLDREV

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.

nom_du_fichier.ext.rNEWREV

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.

You can either launch an external merge tool / conflict editor with TortoiseSVNEdit Conflicts or you can use any text editor to resolve the conflict manually. You should decide what the code should look like, do the necessary changes and save the file. Using a merge tool such as TortoiseMerge or one of the other popular tools is generally the easier option as they generally present the files involved in a 3-pane view and you don't have to worry about the conflict markers. If you do use a text editor then you should search for lines starting with the string <<<<<<<.

Exécutez ensuite la commande TortoiseSVNRésolu... et livrez vos modifications au dépôt. Veuillez noter que la commande de résolution ne résout pas vraiment le conflit. Il 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..., livrez ensuite 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 TortoiseSVNRé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.

Conflits de propriété

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

If one of the changes must override the other then choose the option to Resolve using local property or Resolve using remote property. If the changes must be merged then select Manually edit property, sort out what the property value should be and mark as resolved.

Conflits dans l'arborescence

Un conflit dans l'arborescence est causé quand un développeur déplace/renomme/supprime un fichier ou un répertoire, qu'un autre développeur a également déplacé/renommé/supprimé ou juste modifé. Plusieurs situations peuvent générer un conflit d'arborescence, et chacune a une solution différente.

Dans Subversion, lorsque qu'un fichier est supprimé, il l'est aussi localement, de ce fait, même s'il génère un conflit d'arborescence, aucune action de résolution de conflit de ne peut être effectuée grâce au menu contextuel du click droit. Utilisez la fenêtre Vérifier les Modifications à la place pour pouvoir accéder aux options Edition des conflits.

TortoiseSVN peut aider à trouver les endroits où fusionner les modifications, mais cela ne résoudra pas tous les conflits.Souvenez vous qu'après une mise à jour la base de travail contiendra la révision des éléments tels qu'ils étaient 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.

Suppression locale, édition de la mise à jour

  1. Le développeur A modifie Foo.c et le livre sur le dépôt.

  2. Le développeur B a renommé simultanément Foo.c en Bar.c dans sa copie de travail, ou simplement supprimé Foo.c ou son répertoire parent.

Une mise à jour de la copie de travail du développeur B mène à un conflit dans l'arborescence:

  • Foo.c a été supprimé de la copie de travail, mais est marqué comme étant en conflit d'arborescence.

  • Si le conflit vient d'un renommage plus que d'une suppression alors Bar.c est marqué comme ajouté, mais ne contient pas les modification 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 Foo.c dans le fichier renommé Bar.c. Pour des 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, en ne faisant que marquer le conflit comme étant résolu, il annule les modifications du développeur A.

The conflict edit dialog offers to merge changes if it can find the original file of the renamed Bar.c. If there are multiple files that are possible move sources, then a button for each of these files is shown which allow you to chose the correct file.

Modification locale, suppression dans la mise à jour

  1. Le développeur A renomme Foo.c en Bar.c et envoie les modifications au dépôt.

  2. Le développeur B modifie Foo.c dans sa copie de travail.

Ou dans le cas d'un déplacement de répertoire ...

  1. Le développeur A déplace le réperetoire parent FooFolder vers BarFolder et soumet celui-ci au dépôt.

  2. Le développeur B modifie Foo.c dans sa copie de travail.

Une mise à jour de la copie de travail du développeur B mène à un conflit dans l'arborescence. Pour un simple conflit de fichier :

  • Bar.c est ajouté dans la copie de travail avec le statut 'normal'.

  • Foo.c est marqué comme ayant été ajouté (avec historique) et étant en conflit dans l'arborescence.

Pour un conflit de répertoire:

  • Bar.c est ajouté dans la copie de travail avec le statut 'normal'.

  • Foo.c est marqué comme ayant été ajouté (avec historique) et étant en conflit dans l'arborescence.

    Foo.c est marqué comme modifié.

Le développeur B doit à présent décider de garder la réorganisation du développeur A et de fusionner ses changement dans le fichier correspondant dans la nouvelle architecture, ou simplement annuler les modifications du développeur A et garder le fichier local.

To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog. Then use the button which shows the correct source file to resolve the conflict.

If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog helps to track down what was moved.

Suppression locale, suppression dans la mise à jour

  1. Le développeur A renomme Foo.c en Bar.c et envoie les modifications au dépôt.

  2. Développeur B déplace Foo.c vers Bix.c .

Une mise à jour de la copie de travail du développeur B mène à un conflit dans l'arborescence:

  • Bix.c est marqué comme ajouté avec l'historique.

  • Bar.c est ajouté dans la copie de travail avec le statut 'normal'.

  • Foo.c est marqué comme étant supprimé et étant en conflit dans l'arborescence.

Pour résoudre ce conflit, le développeur B doit trouver à quel fichier renommé/déplacé correspond la version conflictueuse de Foo.c dans le dépôt. Ce peut être fait en utilisant la fenêtre de log.

Le développeur B doit alors décider quel nouveau nom de Foo.cgarder - celui du développeur A ou celui issu du renommage qu'il a lui même effectué.

Dès que le développeur B a résolu manuellement le conflit, l'arborescence des conflits doit être marquée comme résolue grâce au bouton approprié dans la fenêtre d'édition des conflits.

Copie locale incomplète, modification dans la mise à jour

  1. Le développeur A travaillant sur le tronc modifie Foo.c et en fait la livraison au dépôt.

  2. Le développeur B travaillant sur une branche renomme Foo.c en Bar.c et en fait la livraison au 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 dans l'arborescence:

  • Bar.c est déjà dans la copie de travail avec le statut 'normal'.

  • Foo.c est marqué comme manquant dans l'arborescence des conflits.

Pour résoudre ce conflit, les développeurs B doit marquer le fichier comme résolu dans la fenêtre de résolution de conflits, lequel sera retiré de la liste des conflits. Le développeur B doit alors décider s'il faut copier le fichier manquant Foo.c depuis le dépôt, ou fusionner Foo.c avec le fichier renommé Bar.c ou simplement s'il faut ignorer les changements en marquant le conflit comme étant résolu et ne 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.

Modification locale, suppression dans la fusion

  1. Le développeur A qui travaille sur le tronc déplace Foo.c vers Bar.c et le livre sur le dépôt.

  2. Le développeur B travaillant sur une branche modifie le fichier Foo.c et l'envoie au dépôt.

  1. Le développeur A travaillant sur le tronc déplace le dossier parent FooFolder vers BarFolder et l'envoie au dépôt.

  2. Le développeur B travaillant sur une branche modifie Foo.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 dans l'arborescence:

  • Bar.c est marqué comme étant ajouté.

  • Foo.c est marqué comme ayant été modifié et étant en conflit dans l'arborescence.

Le développeur B doit à présent décider de garder la réorganisation du développeur A et de fusionner ses changement dans le fichier correspondant dans la nouvelle architecture, ou simplement annuler les modifications du développeur A et garder le fichier local.

To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted.

If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog for the merge source helps to track down what was moved.

Suppression locale, suppression dans la fusion

  1. Le développeur A qui travaille sur le tronc déplace Foo.c vers Bar.c et le livre sur le dépôt.

  2. Le développeur B qui travaille sur une branche déplace Foo.c vers Bix.c et le livre sur 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 dans l'arborescence:

  • Bix.c est marqué comme étant dans un état normal (non modifé).

  • Bar.c est marqué comme ajouté avec son historique.

  • Foo.c est marqué comme manquant et générant une erreur dans l'arborescence.

To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source.

Le développeur B doit alors décider quel nouveau nom de Foo.cgarder - celui du développeur A ou celui issu du renommage qu'il a lui même effectué.

Dès que le développeur B a résolu manuellement le conflit, l'arborescence des conflits doit être marquée comme résolue grâce au bouton approprié dans la fenêtre d'édition des conflits.

Autres conflits dans l'arborescence

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 portant le même nom à la fois dans le tronc et les branches puis que vous essayez de fusionner, vous obtiendrez un conflit. 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 permettre à SVN de supprimer celui de la cible puis exécuter à nouveau la fusion. Si vous aves besoin de quelque chose de plus complexe, vous devrez le faire manuellement.