SVNBOOK Chap4 Branching and Merging Advanced Merging Cherrypicking
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Sub Versif | SVF | Traduction | Fait |
| Hotshot92 | Relecture | Fait | |
| Validation |
Sommaire |
Titre
Cherrypicking
Sélectionner à la main
Paragraphe 1
Just as the term "changeset" is often used in version control systems, so is the term cherrypicking. This word refers to the act of choosing one specific changeset from a branch and replicating it to another. Cherrypicking may also refer to the act of duplicating a particular set of (not necessarily contiguous!) changesets from one branch to another. This is in contrast to more typical merging scenarios, where the "next" contiguous range of revisions is duplicated automatically.
De la même façon que le terme "ensemble de modifications" est utilisé couramment dans les systèmes de gestion de versions, le terme "sélectionner à la main" pourrait l'être aussi. Il désigne l'action de choisir une liste de modifications particulière au sein d'une branche et de la recopier dans une autre. Sélectionner à la main peut aussi faire référence à l'action de dupliquer un ensemble de modifications (pas nécessairement contigües) d'une branche vers une autre. Ceci est en opposition avec des scénarios de fusion plus courants, où l'ensemble de révisions contigües "suivant" est dupliqué automatiquement.
Paragraphe 2
Why would people want to replicate just a single change? It comes up more often than you'd think. For example, let's go back in time and imagine that you haven't yet merged your private feature branch back to the trunk. At the water cooler, you get word that Sally made an interesting change to integer.c on the trunk. Looking over the history of commits to the trunk, you see that in revision 355 she fixed a critical bug that directly impacts the feature you're working on. You might not be ready to merge all the trunk changes to your branch just yet, but you certainly need that particular bug fix in order to continue your work.
Pourquoi certains voudraient-ils ne recopier qu'une modification unique ? Cela arrive plus souvent qu'on ne croit. Par exemple, remontons le temps et imaginons que vous n'avez pas encore réintégré votre branche de développement privée dans le tronc. A la machine à café, vous apprenez par hasard que Sally a apporté une modification intéressante à entier.c dans le tronc. Vous reportant à l'historique des livraisons du tronc, vous vous apercevez qu'elle a corrigé un bogue crucial en révision 355, qui impacte directement la fonctionnalité sur laquelle vous êtes en train de travailler. Vous n'êtes peut-être pas encore prêt à fusionner toutes les modifications du tronc dans votre branche, mais vous avez certainement besoin de ce correctif pour continuer votre travail.
Paragraphe 3
$ svn diff -c 355 http://svn.example.com/repos/calc/trunk Index: integer.c =================================================================== --- integer.c (revision 354) +++ integer.c (revision 355) @@ -147,7 +147,7 @@ case 6: sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break; case 7: sprintf(info->operating_system, "Macintosh"); break; case 8: sprintf(info->operating_system, "Z-System"); break; - case 9: sprintf(info->operating_system, "CP/MM"); + case 9: sprintf(info->operating_system, "CP/M"); break; case 10: sprintf(info->operating_system, "TOPS-20"); break; case 11: sprintf(info->operating_system, "NTFS (Windows NT)"); break; case 12: sprintf(info->operating_system, "QDOS"); break;
$ svn diff -c 355 http://svn.exemple.com/depot/calc/trunk Index: entier.c =================================================================== --- entier.c (revision 354) +++ entier.c (revision 355) @@ -147,7 +147,7 @@ case 6: sprintf(info->operating_system, "HPFS (OS/2 ou NT)"); break; case 7: sprintf(info->operating_system, "Macintosh"); break; case 8: sprintf(info->operating_system, "Z-System"); break; - case 9: sprintf(info->operating_system, "CP/MM"); + case 9: sprintf(info->operating_system, "CP/M"); break; case 10: sprintf(info->operating_system, "TOPS-20"); break; case 11: sprintf(info->operating_system, "NTFS (Windows NT)"); break; case 12: sprintf(info->operating_system, "QDOS"); break;
Paragraphe 4
Just as you used svn diff in the prior example to examine revision 355, you can pass the same option to svn merge:
De la même façon que vous avez utilisé svn diff dans l'exemple précédent pour examiner la révision 355, vous pouvez passer le même paramètre à svn merge :
Paragraphe 5
$ svn merge -c 355 http://svn.example.com/repos/calc/trunk U integer.c $ svn status M integer.c
$ svn merge -c 355 http://svn.exemple.com/depot/calc/trunk U entier.c $ svn status M entier.c
Paragraphe 6
You can now go through the usual testing procedures before committing this change to your branch. After the commit, Subversion marks r355 as having been merged to the branch so that future "magic" merges that synchronize your branch with the trunk know to skip over r355. (Merging the same change to the same branch almost always results in a conflict!)
Vous pouvez à présent lancer les procédures habituelles de tests, avant de livrer cette modification à votre branche. Après la propagation, Subversion marque r355 comme ayant été fusionnée dans la branche, afin qu'une future fusion "magique", qui synchronisera votre branche avec le tronc, sache qu'elle doit sauter r355 (Fusionner une même modification dans une même branche aboutit presque toujours à un conflit !).
Paragraphe 7
$ cd my-calc-branch $ svn propget svn:mergeinfo . /trunk:341-349,355 # Notice that r355 isn't listed as "eligible" to merge, because # it's already been merged. $ svn mergeinfo http://svn.example.com/repos/calc/trunk --show-revs eligible r350 r351 r352 r353 r354 r356 r357 r358 r359 r360 $ svn merge http://svn.example.com/repos/calc/trunk --- Merging r350 through r354 into '.': U . U integer.c U Makefile --- Merging r356 through r360 into '.': U . U integer.c U button.c
$ cd ma-branche-calc $ svn propget svn:mergeinfo . /trunk:341-349,355 # Remarquez que r355 n'est pas listée comme "éligible" à la fusion, # parce qu'elle a déjà été fusionnée. $ svn mergeinfo http://svn.exemple.com/depot/calc/trunk --show-revs eligible r350 r351 r352 r353 r354 r356 r357 r358 r359 r360 $ svn merge http://svn.example.com/depot/calc/trunk --- Fusion de r350 à r354 dans '.': U . U entier.c U Makefile --- Fusion de r356 à r360 dans '.': U . U entier.c U bouton.c
Paragraphe 8
This use case of replicating (or backporting) bug fixes from one branch to another is perhaps the most popular reason for cherrypicking changes; it comes up all the time, for example, when a team is maintaining a "release branch" of software. (We discuss this pattern in the section called "Release Branches".)
Ce type d'utilisation de la copie (ou rétroproduction) de correctifs d'une branche à une autre est peut-être la raison la plus répandue pour sélectionner à la main des modifications ; le cas se présente très souvent, par exemple lorsqu'une équipe gère une "branche de production" du logiciel (nous développerons ce thème dans le paragraphe appelé "Branches de production").
Paragraphe 9
Did you notice how, in the last example, the merge invocation caused two distinct ranges of merges to be applied? The svn merge command applied two independent patches to your working copy to skip over changeset 355, which your branch already contained. There's nothing inherently wrong with this, except that it has the potential to make conflict resolution trickier. If the first range of changes creates conflicts, you must resolve them interactively for the merge process to continue and apply the second range of changes. If you postpone a conflict from the first wave of changes, the whole merge command will bail out with an error message. [22]
Avez-vous remarqué la façon dont, dans le dernier exemple, le lancement de merge a eu pour effet l'application de deux ensembles distincts de fusions ? La commande svn merge a appliqué deux correctifs indépendants à votre copie de travail, afin de sauter l'ensemble de modifications 355, que votre branche contenait déjà. Il n'y a rien de mal en soi là-dedans, sauf que ça risque de rendre plus délicate la résolution des conflits. Si le premier groupe de modifications engendre des conflits, vous devrez les résoudre de façon interactive pour que la procédure de fusion puisse continuer et appliquer le deuxième groupe de modifications. Si vous remettez à plus tard un conflit lié à la première vague de modifications, la commande merge renverra au final un message d'erreur [22].
Paragraphe 10
A word of warning: while svn diff and svn merge are very similar in concept, they do have different syntax in many cases. Be sure to read about them in Chapter 9, Subversion Complete Reference for details, or ask svn help. For example, svn merge requires a working copy path as a target, that is, a place where it should apply the generated patch. If the target isn't specified, it assumes you are trying to perform one of the following common operations:
- You want to merge directory changes into your current working directory.
- You want to merge the changes in a specific file into a file by the same name that exists in your current working directory.
Avertissement : bien que svn diff et svn merge soient très similaires au niveau conceptuel, leur syntaxe est différente dans de nombreux cas. Pour plus de détails, reportez-vous au Chapitre 9, Guide de référence des commandes Subversion, ou consultez svn help. Par exemple, svn merge demande en entrée, en tant que cible, un chemin vers une copie de travail, c'est-à-dire un emplacement où il va appliquer le correctif généré. Si la cible n'est pas spécifiée, il suppose que vous essayez d'exécuter l'une des opérations suivantes :
- Vous voulez fusionner les modifications du dossier dans votre dossier de travail en cours.
- Vous voulez fusionner les modifications d'un fichier donné dans un fichier du même nom existant dans votre dossier de travail en cours.
Titre du chapitre 9 à valider / corriger le moment venu.
Paragraphe 11
If you are merging a directory and haven't specified a target path, svn merge assumes the first case and tries to apply the changes into your current directory. If you are merging a file, and that file (or a file by the same name) exists in your current working directory, svn merge assumes the second case and tries to apply the changes to a local file with the same name.
Si vous fusionnez un dossier et que vous n'avez pas encore spécifié de cible, svn merge supposera qu'il est dans la première situation et essaiera d'appliquer les modifications dans votre dossier en cours. Si vous fusionnez un fichier, et que ce fichier (ou un fichier du même nom) existe dans votre dossier de travail en cours, svn merge supposera qu'il est dans la seconde situation et essaiera d'appliquer les modifications au fichier local du même nom.
