Quand les branches sont utilisées pour maintenir des lignes séparées de développement, à une certaine étape vous voudrez fusionner les changements faits sur une branche vers le tronc, ou vice versa.
It is important to understand how branching and merging works in Subversion before you start using it, as it can become quite complex. It is highly recommended that you read the chapter Branching and Merging in the Subversion book, which gives a full description and many examples of how it is used.
The next point to note is that merging always takes place within a working copy. If you want to merge changes into a branch, you have to have a working copy for that branch checked out, and invoke the merge wizard from that working copy using → .
En général, c'est une bonne idée d'exécuter une fusion dans une copie de travail inchangée. Si vous avez fait d'autres changements à votre CdT, livrez les d'abord. Si la fusion ne se déroule pas comme prévu, vous pouvez vouloir annuler les changements et la commande Revenir en arrière supprimera tous les changements en incluant ceux effectués avant la fusion.
There are three common use cases for merging which are handled in slightly different ways, as described below. The first page of the merge wizard asks you to select the method you need.
- Fusionner une plage de révisions
Cette méthode couvre le cas où vous avez fait une ou plusieurs révisions sur une branche (ou sur le tronc) et vous voulez reporter ces changements vers une autre branche.
Ce que vous demandez à Subversion est de : « Calculer les modifications nécessaires pour passer [DE] la révision 1 de la branche A [A] la révision 7 de la branche A, et d'appliquer ces modifications à la copie de travail (de la racine ou de la branche B). »
- Réintégrer une branche
This method covers the case when you have made a feature branch as discussed in the Subversion book. All trunk changes have been ported to the feature branch, week by week, and now the feature is complete you want to merge it back into the trunk. Because you have kept the feature branch synchronized with the trunk, the latest versions of branch and trunk will be absolutely identical except for your branch changes.
This is a special case of the tree merge described below, and it requires only the URL to merge from (normally) your development branch. It uses the merge-tracking features of Subversion to calculate the correct revision ranges to use, and perform additional checks which ensure that the branch has been fully updated with trunk changes. This ensures that you don't accidentally undo work that others have committed to trunk since you last synchronized changes.
Après la fusion, toutes les branches de développement ont été complètement fusionnées avec la version de tête. La branches est donc redondante et peut être supprimée.
Once you have performed a reintegrate merge you should not continue to use it for development. The reason for this is that if you try to resynchronize your existing branch from trunk later on, merge tracking will see your reintegration as a trunk change that has not yet been merged into the branch, and will try to merge the branch-to-trunk merge back into the branch! The solution to this is simply to create a new branch from trunk to continue the next phase of your development.
- Fusionner deux arborescences différentes
This is a more general case of the reintegrate method. What you are asking Subversion to do is: « Calculate the changes necessary to get [FROM] the head revision of the trunk [TO] the head revision of the branch, and apply those changes to my working copy (of the trunk). » The net result is that trunk now looks exactly like the branch.
If your server/repository does not support merge-tracking then this is the only way to merge a branch back to trunk. Another use case occurs when you are using vendor branches and you need to merge the changes following a new vendor drop into your trunk code. For more information read the chapter on vendor branches in the Subversion Book.
In the From: field enter the full folder URL of the branch or tag containing the changes you want to port into your working copy. You may also click to browse the repository and find the desired branch. If you have merged from this branch before, then just use the drop down list which shows a history of previously used URLs.
In the Revision range to merge field enter the list of revisions you want to merge. This can be a single revision, a list of specific revisions separated by commas, or a range of revisions separated by a dash, or any combination of these.
Important
There is an important difference in the way a revision range is specified with TortoiseSVN compared to the command line client. The easiest way to visualise it is to think of a fence with posts and fence panels.
Avec le client en ligne de commande vous spécifiez les modifications à fusionner avec deux révisions « limites » qui spécifient les bornes avant et après.
With TortoiseSVN you specify the changeset to merge using « fence panels ». The reason for this becomes clear when you use the log dialog to specify revisions to merge, where each revision appears as a changeset.
If you are merging revisions in chunks, the method shown in the subversion book will have you merge 100-200 this time and 200-300 next time. With TortoiseSVN you would merge 100-200 this time and 201-300 next time.
This difference has generated a lot of heat on the mailing lists. We acknowledge that there is a difference from the command line client, but we believe that for the majority of GUI users it is easier to understand the method we have implemented.
The easiest way to select the range of revisions you need is to click on , as this will list recent changes with their log comments. If you want to merge the changes from a single revision, just select that revision. If you want to merge changes from several revisions, then select that range (using the usual Shift-modifier). Click on and the list of revision numbers to merge will be filled in for you.
Si vous voulez revenir sur des modifications déjà livrées de votre copie de travail, sélectionnez les révisions à annuler et vérifiez bien que la case Fusion inversée est cochée.
If you have already merged some changes from this branch, hopefully you will have made a note of the last revision merged in the log message when you committed the change. In that case, you can use for the Working Copy to trace that log message. Remembering that we are thinking of revisions as changesets, you should Use the revision after the end point of the last merge as the start point for this merge. For example, if you have merged revisions 37 to 39 last time, then the start point for this merge should be revision 40.
If you are using the merge tracking features of Subversion, you do not need to remember which revisions have already been merged - Subversion will record that for you. If you leave the revision range blank, all revisions which have not yet been merged will be included. Read la section intitulée « Suivi des fusions » to find out more.
Si d'autres personnes peuvent livrer des changements alors soyez prudents en utilisant de la révision HEAD. Elle peut ne pas faire référence à la révision à laquelle vous pensez si quelqu'un d'autre a fait une livraison après votre dernière mise à jour.
Cliquez le bouton et allez à la section intitulée « Options de fusion »
To merge a feature branch back into the trunk you must start the merge wizard from within a working copy of the trunk.
In the From URL: field enter the full folder URL of the branch that you want to merge back. You may also click to browse the repository.
There are some conditions which apply to a reintegrate merge. Firstly, the server must support merge tracking. The working copy must be of depth infinite (no sparse checkouts), and it must not have any local modifications, switched items or items that have been updated to revisions other than HEAD. All changes to trunk made during branch development must have been merged across to the branch (or marked as having been merged). The range of revisions to merge will be calculated automatically.
If you are using this method to merge a feature branch back to trunk, you need to start the merge wizard from within a working copy of trunk.
In the From: field enter the full folder URL of the trunk. This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes. You may also click to browse the repository.
Remplissez le champ To: par l'adresse complète de la branche.
Dans les deux champs Depuis la révision et À la révision, entrez le numéro de la dernière révision à laquelle les deux arbres ont été synchronisés. Si vous êtes sûrs que personne d'autre ne fait de livraisons vous pouvez utiliser la révision HEAD dans les deux cas. S'il y a une chance que quelqu'un d'autre puisse avoir fait une livraison depuis cette synchronisation, utilisez le numéro de la révision particulière pour éviter pour perdre des livraisons plus récentes.
Vous pouvez également utiliser pour sélectionner la révision.
This page of the wizard lets you specify advanced options, before starting the merge process. Most of the time you can just use the default settings.
You can specify the depth to use for the merge, i.e. how far down into your working copy the merge should go. The depth terms used are described in la section intitulée « Profondeur d'extraction ». The default depth is Working copy, which uses the existing depth setting, and is almost always what you want.
Most of the time you want merge to take account of the file's history, so that changes relative to a common ancestor are merged. Sometimes you may need to merge files which are perhaps related, but not in your repository. For example you may have imported versions 1 and 2 of a third party library into two separate directories. Although they are logically related, Subversion has no knowledge of this because it only sees the tarballs you imported. If you attempt to merge the difference between these two trees you would see a complete removal followed by a complete add. To make Subversion use only path-based differences rather than history-based differences, check the Ignore ancestry box. Read more about this topic in the Subversion book, Noticing or Ignoring Ancestry
You can specify the way that line ending and whitespace changes are handled. These options are described in la section intitulée « Options de fins de ligne et d'espacement ». The default behaviour is to treat all whitespace and line-end differences as real changes to be merged.
If you are using merge tracking and you want to mark a revision as having been merged, without actually doing the merge here, check the Only record the merge checkbox. There are two possible reasons you might want to do this. It may be that the merge is too complicated for the merge algorithms, so you code the changes by hand, then mark the change as merged so that the merge tracking algorithm is aware of it. Or you might want to prevent a particular revision from being merged. Marking it as already merged will prevent the merge occurring with merge-tracking-aware clients.
Now everything is set up, all you have to do is click on the button. If you want to preview the results performs the merge operation, but does not modify the working copy at all. It shows you a list of the files that will be changed by a real merge, and notes those areas where conflicts will occur.
The merge progress dialog shows each stage of the merge, with the revision ranges involved. This may indicate one more revision than you were expecting. For example if you asked to merge revision 123 the progress dialog will report « Merging revisions 122 through 123 ». To understand this you need to remember that Merge is closely related to Diff. The merge process works by generating a list of differences between two points in the repository, and applying those differences to your working copy. The progress dialog is simply showing the start and end points for the diff.
The merge is now complete. It's a good idea to have a look at the merge and see if it's as expected. Merging is usually quite complicated. Conflicts often arise if the branch has drifted far from the trunk.
For Subversion clients and servers prior to 1.5, no merge information is stored and merged revisions have to be tracked manually. When you have tested the changes and come to commit this revision, your commit log message should always include the revision numbers which have been ported in the merge. If you want to apply another merge at a later time you will need to know what you have already merged, as you do not want to port a change more than once. For more information about this, refer to Best Practices for Merging in the Subversion book.
If your server and all clients are running Subversion 1.5 or higher, the merge tracking facility will record the revisions merged and avoid a revision being merged more than once. This makes your life much simpler as you can simply merge the entire revision range each time and know that only new revisions will actually be merged.
La gestion de branches est importante. Si vous voulez conserver cette branche à jour avec le tronc, vous devriez vous assurer de fusionner souvent pour que la branche et le tronc ne dérivent pas trop loin. Bien sûr, vous devriez toujours éviter la fusion répétée de changements, comme expliquée ci-dessus.
Astuce
If you have just merged a feature branch back into the trunk, the trunk now contains all the new feature code, and the branch is obsolete. You can now delete it from the repository if required.
Important
Subversion can't merge a file with a folder and vice versa - only folders to folders and files to files. If you click on a file and open up the merge dialog, then you have to give a path to a file in that dialog. If you select a folder and bring up the dialog, then you must specify a folder URL for the merge.
Subversion 1.5 introduced facilities for merge tracking. When you merge changes from one tree into another, the revision numbers merged are stored and this information can be used for several different purposes.
Vous pouvez éviter ke danger de fusionner deux fois la même révision(problème de fusions répétées). Dès qu'une révision a été marquée comme ayant été fusionnée, les fusions futures incluant cette révision dans leur plage de révisions l'ignoreront.
Quand vous fusionnez une branche dans le trunk, la fenêtre de log peut vous montrer les livraisons de la branche comme faisant partie des messages de log du trunk, donnant une meilleure traçabilité des modifications.
When you show the log dialog from within the merge dialog, revisions already merged are shown in grey.
Quand l'information de bannissement d'un fichier est affichée, vous pouvez choisir de montrer les auteurs des révisions fusionnées, au lieu de la personne ayant fait la fusion.
Vous pouvez marquer les révisions comme n'étant pas à fusionner en les incluant dans la liste des révisions fusionnées mais sans vraiment faire la fusion.
Merge tracking information is stored in the svn:mergeinfo property by the client when it performs a merge. When the merge is committed the server stores that information in a database, and when you request merge, log or blame information, the server can respond appropriately. For the system to work properly you must ensure that the server, the repository and all clients are upgraded. Earlier clients will not store the svn:mergeinfo property and earlier servers will not provide the information requested by new clients.
Find out more about merge tracking from Subversion's Merge tracking documentation.
Merging does not always go smoothly. Sometimes there is a conflict, and if you are merging multiple ranges, you generally want to resolve the conflict before merging of the next range starts. TortoiseSVN helps you through this process by showing the merge conflict callback dialog.
Quand la fusion génère un conflit, vous avez trois moyens de le gérer :
You may decide that your local changes are much more important, so you want to discard the version from the repository and keep your local version. Or you might discard your local changes in favour of the repository version. Either way, no attempt is made to merge the changes - you choose one or the other.
Normally you will want to look at the conflicts and resolve them. In that case, choose the which will start up your merge tool. When you are satisfied with the result, click .
The last option is to postpone resolution and continue with merging. You can choose to do that for the current conflicted file, or for all files in the rest of the merge. However, if there are further changes in that file, it will not be possible to complete the merge.
If you do not want to use this interactive callback, there is a checkbox in the merge progress dialog Merge non-interactive. If this is set for a merge and the merge would result in a conflict, the file is marked as in conflict and the merge goes on. You will have to resolve the conflicts after the whole merge is finished. If it is not set, then before a file is marked as conflicted you get the chance to resolve the conflict during the merge. This has the advantage that if a file gets multiple merges (multiple revisions apply a change to that file), subsequent merges might succeed depending on which lines are affected. But of course you can't walk away to get a coffee while the merge is running ;)
If you want to merge all changes from a feature branch back to trunk, then you can use the → from the extended context menu (hold down the Shift key while you right click on the file).
This dialog is very easy. All you have to do is set the options for the merge, as described in la section intitulée « Options de fusion ». The rest is done by TortoiseSVN automatically using merge tracking.
Quand vous développez une nouvelle fonctionnalité dans une branche séparée c'est une bonne pratique de garder en tête la réintégration de cette branche lorsque la nouvelle fonctionnalité sera prête. Si la branche principale (la trunk) évolue en même temps, il est probable que les différences seront nombreuses, rendant l'intégration cauchemardesque.
Si la fonctionnalité est relativement simple et que le développement ne prend pas beaucoup de temps, vous pouvez adoptez une solution simple, qui consiste à garder une branche distincte, que vous intégrerez lorsque le développement sera fini. Dans l'assistant de fusion, ce devrait n'être qu'un simple Fusionner une gamme de révisions, la gamme de révisions couvrant la période de développement de la branche.
If the feature is going to take longer and you need to account for changes in trunk, then you need to keep the branch synchronised. This simply means that periodically you merge trunk changes into the branch, so that the branch contains all the trunk changes plus the new feature. The synchronisation process uses Merge a range of revisions. When the feature is complete then you can merge it back to trunk using either Reintegrate a branch or Merge two different trees.