SVNBOOK Chap4 Branching and Merging Advanced Merging More on Merge Conflicts
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Sub Versif | SVF | Traduction | Fait |
| Hotshot92 | 1ere Relecture | Fait | |
| Validation |
Sommaire |
Titre
More on Merge Conflicts
Plus de détails sur les conflits liés aux fusions
Paragraphe 1
Just like the svn update command, svn merge applies changes to your working copy. And therefore it's also capable of creating conflicts. The conflicts produced by svn merge, however, are sometimes different, and this section explains those differences.
Tout comme la commande svn update, svn merge applique les modifications à votre copie de travail. Elle est donc aussi susceptible de créer des conflits. Cependant, les conflits engendrés par svn merge sont parfois différents et ce paragraphe va expliquer ces différences.
Paragraphe 2
To begin with, assume that your working copy has no local edits. When you svn update to a particular revision, the changes sent by the server will always apply "cleanly" to your working copy. The server produces the delta by comparing two trees: a virtual snapshot of your working copy, and the revision tree you're interested in. Because the left hand side of the comparison is exactly equal to what you already have, the delta is guaranteed to correctly convert your working copy into the right hand tree.
Pour commencer, supposons que votre copie de travail n'a pas de modification locale en cours. Quand vous lancerez svn update pour la mettre à jour à une révision particulière, les modifications envoyées par le serveur s'appliqueront toujours "proprement" à votre copie de travail. Le serveur génère le delta en comparant deux arborescences : d'une part un cliché virtuel instantané de votre copie de travail, d'autre part l'arborescence de la révision qui vous intéresse. Parce que la partie gauche de la comparaison est parfaitement égale à ce que vous avez déjà, il est garanti que le delta va convertir correctement votre copie de travail en l'arborescence de droite.
Paragraphe 3
But svn merge has no such guarantees and can be much more chaotic: the advanced user can ask the server to compare any two trees at all, even ones that are unrelated to the working copy! This means there's large potential for human error. Users will sometimes compare the wrong two trees, creating a delta that doesn't apply cleanly. svn merge will do its best to apply as much of the delta as possible, but some parts may be impossible. Just as the Unix patch command sometimes complains about "failed hunks," svn merge will similarly complain about "skipped targets":
Mais svn merge ne dispose pas de telles garanties et peut être bien plus chaotique : l'utilisateur avancé peut demander au serveur de comparer n'importe quelle paire d'arborescences, même des arborescences qui sont sans rapport avec la copie de travail ! Ce qui laisse potentiellement beaucoup de place à l'erreur humaine. Les utilisateurs vont parfois comparer deux arborescences qui ne sont pas les bonnes, créant ainsi un delta qui ne s'appliquera pas proprement. svn merge fera de son mieux pour appliquer la plus grande partie possible du delta, mais ça risque d'être impossible pour certains morceaux. De la même façon que la commande Unix patch se plaint parfois de "morceaux ratés" ("failed hunks"), svn merge se plaindra de "cibles manquantes omises" ("skipped targets") :
Paragraphe 4
$ svn merge -r 1288:1351 http://svn.example.com/repos/branch U foo.c U bar.c Skipped missing target: 'baz.c' U glub.c U sputter.h Conflict discovered in 'glorb.h'. Select: (p) postpone, (df) diff-full, (e) edit, (h) help for more options:
$ svn merge -r 1288:1351 http://svn.exemple.com/depot/branche U truc.c U bidule.c Cible manquante omise : 'baz.c' U blob.c U machin.h Conflit découvert dans 'glorb.h'. Sélectionner : (p) report, (df) diff complet, (e) édite, (h) aide pour plus d'options :
Paragraphe 5
In the previous example, it might be the case that baz.c exists in both snapshots of the branch being compared, and the resultant delta wants to change the file's contents, but the file doesn't exist in the working copy. Whatever the case, the "skipped" message means that the user is most likely comparing the wrong two trees; it's the classic sign of user error. When this happens, it's easy to recursively revert all the changes created by the merge (svn revert . --recursive), delete any unversioned files or directories left behind after the revert, and rerun svn merge with different arguments.
Dans l'exemple précédent, il est possible que baz.c existe dans les deux instantanés de la branche en question ; et que le delta résultant tente de modifier le contenu du fichier, mais que le fichier n'existe pas dans la copie de travail. Quoi qu'il en soit, le message "Cible manquante omise" signifie que l'utilisateur compare probablement les mauvaises arborescences ; c'est le signe classique d'une erreur de l'utilisateur. Quand ça arrive, c'est facile de revenir en arrière de manière récursive sur toutes les modifications créées par la fusion (svn revert . --recursive), effacer tout fichier ou dossier non-versionné restant après le retour en arrière, et relancer svn merge avec des paramètres différents.
Paragraphe 6
Also notice that the preceding example shows a conflict happening on glorb.h. We already stated that the working copy has no local edits: how can a conflict possibly happen? Again, because the user can use svn merge to define and apply any old delta to the working copy, that delta may contain textual changes that don't cleanly apply to a working file, even if the file has no local modifications.
Remarquez également que l'exemple précédent indique un conflit sur glorb.h. Nous avons déjà mentionné que la copie de travail n'a pas de modifications locales en cours : comment peut-il donc y avoir conflit ? Encore une fois, parce que l'utilisateur peut utiliser svn merge pour definir et appliquer n'importe quel vieux delta à la copie de travail, ce delta risque de contenir des modifications textuelles qui ne s'appliquent pas proprement à un fichier de la copie de travail, même si ce fichier n'a pas de modifications locales en cours.
Paragraphe 7
Another small difference between svn update and svn merge is the names of the full-text files created when a conflict happens. In the section called "Resolve Conflicts (Merging Others' Changes)", we saw that an update produces files named filename.mine, filename.rOLDREV, and filename.rNEWREV. When svn merge produces a conflict, though, it creates three files named filename.working, filename.left, and filename.right. In this case, the terms "left" and "right" are describing which side of the double-tree comparison the file came from. In any case, these differing names will help you distinguish between conflicts that happened as a result of an update and ones that happened as a result of a merge.
Une autre petite différence entre svn update et svn merge concerne les noms des fichiers textes créés quand un conflit a lieu. Dans le paragraphe nommé "Résoudre les conflits (Fusionner des modifications)", nous avons vu qu'une mise à jour génère des fichiers appelés nomdufichier.mine, nomdufichier.rOLDREV et nomdufichier.rNEWREV. Cependant, quand svn merge cause un conflit, il crée trois fichiers appelés nomdufichier.working, nomdufichier.left et nomdufichier.right. Dans ce cas, les termes "left" et "right" décrivent de quel côté de la double comparaison d'arborescences le fichier venait. Dans tous les cas, ces noms de fichiers différents vous aideront à distinguer les conflits résultant d'une mise à jour de ceux résultant d'une fusion.
