SVNBOOK Chap4 Branching and Merging Vendor Branches General Vendor Branch Management Procedure
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
General Vendor Branch Management Procedure
Procédure générale de gestion des branches fournisseur
Paragraphe 1
Managing vendor branches generally works like this: first, you create a top-level directory (such as /vendor) to hold the vendor branches. Then you import the third-party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (e.g., /trunk) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking, you bring it into the vendor branch and merge the changes into /trunk, resolving whatever conflicts occur between your local changes and the upstream changes.
La gestion des branches fournisseur fonctionne généralement de la façon suivante : vous créez d'abord un répertoire à la racine (par exemple /fournisseur) qui contiendra les branches fournisseur. Ensuite vous importez le code tierce dans un sous-dossier de ce dossier racine. Vous copiez ensuite ce sous-répertoire vers l'emplacement approprié de votre branche de développement principale (par exemple /trunk). Vous effectuez toujours vos modifications locales dans la branche de développement principale. À chaque nouvelle version du code tierce, vous le déposez dans la branche fournisseur et en fusionnez les modifications vers /trunk, en résolvant les conflits qui apparaissent entre vos modifications locales et les modifications tierces.
Paragraphe 2
An example will help to clarify this algorithm. We'll use a scenario where your development team is creating a calculator program that links against a third-party complex number arithmetic library, libcomplex. We'll begin with the initial creation of the vendor branch and the import of the first vendor drop. We'll call our vendor branch directory libcomplex, and our code drops will go into a subdirectory of our vendor branch called current. And since svn import creates all the intermediate parent directories it needs, we can actually accomplish both of these steps with a single command:
Un exemple va rendre cet algorithme plus clair. Nous allons utiliser un scénario dans lequel votre équipe de développement crée un programme de calcul qui dépend d'une bibliothèque tierce d'arithmétique des nombres complexes, libcomplex. Nous commencerons par la création initiale de la branche fournisseur et l'import de la première livraison fournisseur. Nous appellerons notre dossier contenant la branche fournisseur libcomplex, et nos livraisons fournisseur iront dans un sous-dossier de notre branche fournisseur appelé actuel. Et puisque svn import crée tous les dossiers parents intermédiaires dont il a besoin, nous pouvons en fait accomplir ces deux étapes en une seule commande :
Paragraphe 3
$ svn import /path/to/libcomplex-1.0 \
http://svn.example.com/repos/vendor/libcomplex/current \
-m 'importing initial 1.0 vendor drop'
...
$ svn import /chemin/vers/libcomplex-1.0 \
http://svn.exemple.com/depot/fournisseur/libcomplex/actuel \
-m 'import initial de la livraison fournisseur 1.0'
...
Paragraphe 4
We now have the current version of the libcomplex source code in /vendor/libcomplex/current. Now, we tag that version (see the section called “Tags”) and then copy it into the main development branch. Our copy will create a new directory called libcomplex in our existing calc project directory. It is in this copied version of the vendor data that we will make our customizations:
Nous avons désormais la version actuelle du code source de libcomplex dans /fournisseur/libcomplex/actuel. Maintenant, nous allons étiqueter cette version (voir le paragraphe appelé "Étiquettes"), et ensuite la copier dans la branche de développement principale. Notre copie créera un nouveau dossier appelé libcomplex au sein du répertoire de notre projet existant calc. C'est dans cette copie des données du fournisseur que nous ferons nos ajustements maison :
Paragraphe 5
$ svn copy http://svn.example.com/repos/vendor/libcomplex/current \ http://svn.example.com/repos/vendor/libcomplex/1.0 \ -m 'tagging libcomplex-1.0' ... $ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0 \ http://svn.example.com/repos/calc/libcomplex \ -m 'bringing libcomplex-1.0 into the main branch' ...
$ svn copy http://svn.exemple.com/depot/fournisseur/libcomplex/actuel \ http://svn.exemple.com/depot/fournisseur/libcomplex/1.0 \ -m 'étiquetage de libcomplex-1.0' ... $ svn copy http://svn.exemple.com/depot/fournisseur/libcomplex/1.0 \ http://svn.exemple.com/depot/calc/libcomplex \ -m 'amène libcomplex-1.0 dans la branche principale' ...
Paragraphe 6
We check out our project's main branch—which now includes a copy of the first vendor drop—and we get to work customizing the libcomplex code. Before we know it, our modified version of libcomplex is now completely integrated into our calculator program. [25]
Nous extrayons ensuite la branche principale de notre projet - qui inclut désormais une copie de la première livraison fournisseur - et nous nous mettons au travail pour personnaliser le code de libcomplex. Avant même d'en avoir pris conscience, notre version modifiée de libcomplex est complètement intégrée dans notre programme de calcul [25].
Paragraphe 7
A few weeks later, the developers of libcomplex release a new version of their library—version 1.1—which contains some features and functionality that we really want. We'd like to upgrade to this new version, but without losing the customizations we made to the existing version. What we essentially would like to do is to replace our current baseline version of libcomplex 1.0 with a copy of libcomplex 1.1, and then re-apply the custom modifications we previously made to that library to the new version. But we actually approach the problem from the other direction, applying the changes made to libcomplex between versions 1.0 and 1.1 to our modified copy of it.
Quelques semaines plus tard, les développeurs de libcomplex publient une nouvelle version de leur bibliothèque - la version 1.1 - qui contient des fonctionnalités dont nous avons besoin. Nous aimerions pouvoir utiliser cette nouvelle version, sans toutefois perdre les évolutions que nous avons apportées à la version existante. En gros, ce que nous voudrions faire c'est remplacer notre version actuelle de libcomplex, la 1.0, par une copie de libcomplex 1.1, et ensuite ré-appliquer les modifications que nous avions effectuées précédemment sur cette bibliothèque à la nouvelle version. Mais en fait nous allons aborder le problème sous un autre angle, en appliquant les changements apportés à libcomplex entre les versions 1.0 et 1.1 à notre copie modifiée de celle-ci.
Paragraphe 8
To perform this upgrade, we check out a copy of our vendor branch and replace the code in the current directory with the new libcomplex 1.1 source code. We quite literally copy new files on top of existing files, perhaps exploding the libcomplex 1.1 release tarball atop our existing files and directories. The goal here is to make our current directory contain only the libcomplex 1.1 code and to ensure that all that code is under version control. Oh, and we want to do this with as little version control history disturbance as possible.
Pour effectuer cette mise à niveau, nous allons extraire une copie de notre branche fournisseur et remplacer le code du répertoire actuel avec le nouveau code source de libcomplex 1.1. Nous copions en fait littéralement de nouveaux fichiers par-dessus des fichiers existants, par exemple en extrayant le contenu de l'archive de libcomplex 1.1 à l'endroit où se trouvent nos fichiers et dossiers. L'objectif ici est d'aboutir à ce que notre répertoire actuel ne contienne que le code de libcomplex 1.1, et de s'assurer que la totalité de ce code est versionné. Ah, et puis nous voulons faire ceci avec le moins possible de perturbations liées à l'historique de la gestion de versions.
Paragraphe 9
After replacing the 1.0 code with 1.1 code, svn status will show files with local modifications as well as, perhaps, some unversioned files. If we did what we were supposed to do, the unversioned files are only those new files introduced in the 1.1 release of libcomplex—we run svn add on those to get them under version control. If the 1.1 code no longer has certain files that were in the 1.0 tree, it may be hard to notice them; you'd have to compare the two trees with some external tool and then svn delete any files present in 1.0 but not in 1.1. (Although it might also be just fine to let these same files live on in unused obscurity!) Finally, once our current working copy contains only the libcomplex 1.1 code, we commit the changes we made to get it looking that way.
Après avoir remplacé le code de la 1.0 par le code de la 1.1, svn status listera les fichiers ayant des modifications locales, et peut-être aussi des fichiers non-versionnés. Si nous avons fait ce que nous étions censés faire, les fichiers non versionnés sont uniquement de nouveaux fichiers introduits par la version 1.1 de libcomplex - nous allons donc lancer svn add sur ces fichiers pour les inclure dans la gestion de versions. Si le code de la 1.1 ne contient plus certains fichiers qui étaient dans l'arborescence de la 1.0, il sera peut-être difficile de les repérer ; il vous faudrait comparer les deux arborescences avec un outil extérieur et ensuite faire un svn delete sur tous les fichiers présents en 1.0 mais pas en 1.1. (bien qu'il soit peut-être parfaitement acceptable de laisser traîner ces mêmes fichiers, inutilisés, dans l'ombre). Finalement, une fois que notre copie de travail actuelle ne contient plus que le code de libcomplex 1.1, nous pouvons propager les modifications que nous avons faites pour lui donner cet aspect.
Paragraphe 10
Our current branch now contains the new vendor drop. We tag the new version as 1.1 (in the same way we previously tagged the version 1.0 vendor drop), and then merge the differences between the tag of the previous version and the new current version into our main development branch:
Notre branche "actuel" contient désormais la nouvelle livraison fournisseur. Nous allons donc étiqueter la nouvelle version en 1.1 (de la même façon qui nous avions précédemment étiqueté la livraison fournisseur de la version 1.0), et ensuite fusionner les différences entre les étiquettes de la version précédente et de la nouvelle version vers notre branche de développement principale :
Paragraphe 11
$ cd working-copies/calc $ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0 \ http://svn.example.com/repos/vendor/libcomplex/current \ libcomplex ... # resolve all the conflicts between their changes and our changes $ svn commit -m 'merging libcomplex-1.1 into the main branch' ...
$ cd copies-de-travail/calc $ svn merge http://svn.exemple.com/depot/fournisseur/libcomplex/1.0 \ http://svn.exemple.com/depot/fournisseur/libcomplex/actuel \ libcomplex ... # résoudre tous les conflits entre leurs modifications et nos modifications $ svn commit -m 'fusion de libcomplex-1.1 vers la branche principale' ...
Paragraphe 12
In the trivial use case, the new version of our third-party tool would look, from a files-and-directories point of view, just like the previous version. None of the libcomplex source files would have been deleted, renamed, or moved to different locations—the new version would contain only textual modifications against the previous one. In a perfect world, our modifications would apply cleanly to the new version of the library, with absolutely no complications or conflicts.
Dans le cas le plus trivial, la nouvelle version de notre outil tierce ressemblerait à la version précédente, du point de vue des fichiers et dossiers. Aucun des fichiers sources de libcomplex n'aurait été effacé, renommé, ou déplacé - la nouvelle version ne contiendrait que des modifications textuelles par rapport à la précédente. Dans l'idéal, nos modifications s'appliqueraient proprement à la nouvelle version de la bibliothèque, sans la moindre complication ou conflit.
Paragraphe 13
But things aren't always that simple, and in fact it is quite common for source files to get moved around between releases of software. This complicates the process of ensuring that our modifications are still valid for the new version of code, and things can quickly degrade into a situation where we have to manually re-create our customizations in the new version. Once Subversion knows about the history of a given source file—including all its previous locations—the process of merging in the new version of the library is pretty simple. But we are responsible for telling Subversion how the source file layout changed from vendor drop to vendor drop.
Mais les choses ne sont pas toujours aussi simples, et il assez fréquent en fait que des fichiers sources changent d'emplacement d'une version à l'autre d'un logiciel. Ceci rend plus compliqué la tâche de s'assurer que nos modifications sont toujours valides pour la nouvelle version du code, et les choses peuvent rapidement dégénérer, jusqu'au point où nous pouvons être forcés de reporter manuellement nos évolutions maison dans la nouvelle version. Une fois que Subversion connaît l'historique d'un fichier source donné, incluant tous ses emplacements précédents, la procédure pour incorporer la nouvelle version de la bibliothèque est assez simple. Mais c'est à nous qu'incombe la responsabilité d'indiquer à Subversion de quelle manière l'agencement des fichiers sources a changé d'une livraison fournisseur à une autre.
