Mientras que las ramas se utilizan para mantener líneas de desarrollo separadas, en alguna etapa tendrá que fusionar los cambios hechos en una rama de vuelta en el tronco, o viceversa.
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.
El siguiente punto a tener en cuenta es que la fusión siempre tiene lugar en una copia de trabajo. Si quiere fusionar cambios en una rama, deberá tener una copia de trabajo obtenida de dicha rama, e invocar el asistente de fusionado desde esa copia de trabajo utilizando → .
En general es una buena idea realizar fusiones en una copia de trabajo sin modificar. Si ha hecho otros cambios en su copia de trabajo, confírmelos primero. Si la fusión no funciona como espera, puede querer revertir los cambios, y el comando Revertir descartará todos los cambios, incluidos cualquiera que haya hecho antes de la fusión.
Hay tres casos de uso comunes para fusionar que se manejan de formas ligeramente diferentes, como se describen a continuación. La primera página del asistente de fusión le pide seleccionar el método que necesita.
- Fusionando un rango de revisiones.
Este método cubre el caso en el que ha hecho una o más revisiones a una rama (o al tronco) y desea portar estos cambios a una rama diferente.
What you are asking Subversion to do is this: “ Calculate the changes necessary to get [FROM] revision 1 of branch A [TO] revision 7 of branch A, and apply those changes to my working copy (of trunk or branch B). ”
If you leave the revision range empty, Subversion uses the merge-tracking features to calculate the correct revision range to use. This is known as a reintegrate or automatic merge.
- Fusionando dos árboles diferentes.
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.
En el campo Desde: introduzca la URL completa de la carpeta de la rama o la etiqueta que contiene los cambios que desea portar a su copia de trabajo. También puede pulsar para navegar el repositorio y encontrar la rama deseada. Si ha fusionado desde esta rama antes, entonces utilice la lista desplegable que le muestra una historia de las URLs utilizadas anteriormente.
If you are merging from a renamed or deleted branch then you will have to go back to a revision where that branch still existed. In this case you will also need to specify that revision as a peg revision in the range of revisions being merged (see below), otherwise the merge will fail when it can't find that path at HEAD.
En el campo Rango de revisiones a fusionar introduzca la lista de revisiones que desea fusionar. Puede ser una única revisión, una lista de revisiones específicas separadas por comas, un rango de revisiones separado por un guión, o cualquier combinación de éstas.
If you need to specify a peg revision for the merge, add the peg revision at the end of the revisions, e.g. 5-7,10@3. In the above example, the revisions 5,6,7 and 10 would be merged, with 3 being the peg revision.
Importante
Hay una diferencia importante en la forma que se especifican los rangos de revisiones en TortoiseSVN comparado con el cliente de línea de comandos. La forma más fácil de visualizar esto es pensar en una valla con postes y paneles.
Con el cliente de línea de comandos se especifican los cambios a fusionar utilizando dos revisiones “postes” que especifican los puntos anterior y posterior.
Con TortoiseSVN se especifican los conjuntos de cambios a fusionar utilizando “paneles de vallas”. La razón para esto queda más clara cuando utiliza el diálogo de registro para seleccionar las revisiones a fusionar, donde cada revisión aparece como un conjunto de cambios.
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.
Esta diferencia ha generado un montón de reacciones en las listas de trabajo. Reconocemos que es una diferencia respecto al cliente de línea de comandos, pero creemos que para la mayoría de usuarios GUI el método que hemos implementado es más fácil de entender.
La manera más sencilla de seleccionar el rango de revisiones que necesita es pulsar en , dado que esto mostrará los cambios recientes con sus comentarios de registro. Si desea fusionar los cambios de una única revisión, seleccione esa revisión. Si desea fusionar los cambios de varias revisiones, entonces seleccione ese rango (utilizando el modificador habitual Mayúsculas). Pulse y la lista de números de revisión a fusionar se rellenará automáticamente.
Si desea fusionar los cambios de nuevo fuera de su copia de trabajo, para revertir un cambio que ya ha sido confirmado, seleccoine las revisiones a revertir y asegúrese que la casilla Fusión inversa está marcada.
Si ya ha fusionado algunos cambios desde esta rama, esperemos que haya apuntado la última revisión fusionada en el mensaje de registro cuando confirmó ese cambio. En ese caso, puede utilizar en la Copia de Trabajo para buscar ese mensaje de registro. Recordando que estamos pensando en las revisiones como conjuntos de cambios, debería utilizar la revisión siguiente al punto final de la última fusión como punto de inicio para esta fusión. Por ejemplo, si la última vez fusionó las revisiones de la 37 a la 39, entonces el punto de inicio de esta fusión sería la revisión 40.
Si está utilizando las características de registro de fusiones de Subversion, no necesita recordar qué revisiones ya han sido fusionadas - Subversion lo apuntará por usted. Si deja el rango de revisiones en blanco, se incluirán todas las revisiones que no hayan sido aún fusionadas. Lea “Registro de fusión” para saber más.
When merge tracking is used, the log dialog will show previously merged revisions, and revisions pre-dating the common ancestor point, i.e. before the branch was copied, as greyed out. The Hide non-mergeable revisions checkbox allows you to filter out these revisions completely so you see only the revisions which can be merged.
Si hay otras personas que puedan estar confirmando cambios, entonces tenga cuidado al utilizar la revisión HEAD. Puede que no se refiera a la revisión que usted cree si alguien más ha hecho una confirmación después de su última actualización.
If you leave the range of revisions empty or have the radio button all revisions checked, then Subversion merges all not-yet merged revisions. This is known as a reintegrate or automatic merge.
Hay algunas condiciones que se aplican a la fusión de reintegración. En primer lugar, el servidor debe soportar el registro de fusiones. La copia de trabajo debe ser de profundidad infinita (sin obtenciones parciales), y no debe tener ninguna modificación local, ítems apuntando a otra ruta o ítems que hayan sido actualizados a otras revisiones distintas de HEAD. Todos los cambios del tronco hechos durante el desarrollo de la rama deben haberse fusionado en la rama (o marcados como que ya han sido fusionados). El rago de revisiones para la fusión se calculará automáticamente.
Clic y vaya a “Opciones de fusión” .
Si está utilizando este método para fusioanr una rama de característica de nuevo en el tronco, necesitará iniciar el asistente de fusión desde una copia de trabajo del tronco.
En el campo Desde: introduzca la URL completa del tronco (trunk). Esto puede sonar erróneo, pero recuerde que el tronco es el punto de inicio al que desea añadir los cambios de la rama. También puede pulsar para navegar el repositorio.
En el campo A: introduzca la URL completa de la rama de la característica.
En los dos campos Desde la Revisión y Hasta la Revisión, introduzca el último número de revisión en el que se sincronizaron los dos árboles. Si está seguro que nadie más está haciendo confirmaciones puede utilizar HEAD en ambos casos. Si hay alguna posibilidad que alguien haya hecho una confirmación desde esa sincronización, utilice el número de revisión específico para evitar perder cambios más recientes.
También puede usar para seleccionar la revisión.
Esta página del asistente le permite especificar opciones avanzadas antes de empezar el proceso de fusión. La mayoría de las veces puede simplemente utilizar las opciones por defecto.
Puede especificar la profundidad de la fusión, es decir, cuántos niveles debe bajar la fusión en su copia de trabajo. Los términos de profundidad se describen en “Profundidad de obtención”. La profundidad por defecto es Copia de trabajo, que utiliza la configuración de profundidad existente, y que casi siempre es lo que quiere hacer.
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.
Puede especificar la forma en la que se manejan los cambios en los finales de línea y en los espacios en blanco. Estas opciones se describen en “Opciones de fín de línea y espacios en blanco”. El comportamiento por defecto es tratar todos los espacios en blanco y las diferencias en los finales de líneas como cambios reales que deben fusionarse.
La casilla marcada como Forzar la fusión is usada para evitar conflictos de árbol en los que un borrado entrante afecta a archivos que o están modificados localmente o ni siquiera están versionados. Si el archivo es eliminado no hay forma de recuperarlo. Esa es la razón por la que esta opción no está marcada por defecto.
Si está utilizando el registro de fusiones y desea marcar una revisión como que ya se ha fusionado, sin hacer realmente efectiva la fusión aquí, marque la casilla Sólo registrar la fusión. Hay dos posibles razones por las que puede querer hacer esto. Puede ser que la fusión es demasiado complicada para los algoritmos de fusión, por lo que hace los cambios en el código a mano, y luego marca el cambio como fusionado para que el algoritmo de registro de fusión se de por enterado. O quizás quiera evitar que una revisión en concreto se fusione. Marcándola como ya fusionada evitará que la fusión se produzca con los clientes manejan la información de registro de fusión.
Ahora que todo está preparado, todo lo que debe hacer es pulsar en el botón . Si quiere previsualizar los resultados, el botón realiza la operación de la fusión, pero no modifica la copia de trabajo en absoluto. Le muestra una lista de archivos que serán cambiados por la fusión real, y le notifica las áreas donde podrían ocurrir conflictos. Ya que el seguimiento de la fusión complica mucho el proceso de fusionado, no hay una forma garantizada de saber de antemano si el fusionado se completará sin conflictos, por lo que ficheros marcados como en conflicto en una prueba de fusión podrían en realidad fusionarse sin problemas.
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.
La fusión ya ha concluído. Es una buena idea observar la fusión y comprobar si el resultado es el esperado. Normalmente fusionar es un proceso complicado. A menudo aparecen conflictos cuando la rama se ha desviado mucho del tronco.
Sugerencia
Whenever revisions are merged into a working copy, TortoiseSVN generates a log message from all the merged revisions. Those are then available from the button in the commit dialog.
To customize that generated message, set the corresponding project properties on your working copy. See “Merge log message templates”
Los clientes y servidores de Subversion anteriores a la versión 1.5 no almacenan la información de fusión, y las revisiones fusionadas deben ser registradas de forma manual. Cuando haya comprobado los cambios y vaya a confirmar esta revisión, su mensaje de registro de confirmación debería incluir siempre los números de revisión que han sido portados en la fusión. Si desea aplicar otra fusión más tarde, necesitará saber lo que ya ha fusionado, porque no querrá portar un cambio más de una vez. Puede encontrar más información sobre esto en Las mejores prácticas para fusionar en el libro de Subversion.
Si su servidor y todos los clientes están ejecutando Subverison 1.5 o superior, las facilidades de registro de fusiones apuntarán las revisiones fusionadas y evitarán que una revisión se fusione más de una vez. Esto le facilita mucho la vida ya que puede simplemente fusionar el rango entero de revisiones cada vez y saber qué sólo las nuevas revisiones serán realmente fusionadas.
El manejo de las ramas es importante. Si desea mantener esta rama actualizada respecto al tronco, debería asegurarse de fusionar a menudo para que la rama y el tronco no se alejen mucho. Por supuesto, sigue debiendo evitar fusiones repetidas de cambios, como se explicó anteriormente.
Sugerencia
Si acaba de fusionar una rama de característica en el tronco, el tronco contiene ahora todo el código de la nueva característica, y la rama es obsoleta. Si lo necesita, puede borrar la rama del repositorio.
Importante
Subversion no puede fusionar un archivo con una carpeta, y viceversa - sólo carpetas con carpetas y archivos con archivos. Si pulsa en un archivo y abre el diálogo de fusionar, entonces deberá darle una ruta a un archivo en ese diálogo. Si selecciona una carpeta y llama al diálogo, debe especificar una URL de una carpeta para la fusión.
Subversion 1.5 introdujo facilidades para el registro de fusiones.. Cuando fusiona cambios de un árbol en otro, los números de revisión fusionados se almacenan, y esta información se puede utilizar para diferentes propósitos.
Puede evitar el peligro de fusionar la misma revisión dos veces (problema de fusiones repetidas). Una vez que una revisión se ha marcado como que ha sido fusionada, las fusiones futuras que incluyan esa revisión en el rango la saltarán.
Cuando fusiona una rama de nuevo al tronco, el diálogo de registro le puede mostrar las confirmaciones de la rama como parte del registro del tronco, proporcionando una mejor trazabilidad de los cambios.
Cuando se meustra el diálogo de registro desde el diálogo de fusión, las revisiones ya fusionadas aparecen en gris.
Cuando muestre información de autoría para un archivo, puede elegir mostrar el autor original de la revisión fusionada, en vez de la persona que hizo la fusión.
Puede marcar revisiones como no fusionar si las incluye en la lista de revisiones fusionadas sin ejecutar relamente la fusión.
La información de registro de fusiones se almacena en la propiedad svn:mergeinfo por parte del cliente cuando realiza la fusión. Cuando la fusión se confirma, el servidor almacena dicha información en una base de datos, y cuando le pide información de la fusión, registro o autoría, el servidor puede responer apropiadamente. Para que el sistema funcione correctamente debe asegurarse que el servidor y todos los clientes estén actualizados. Los clientes antiguos no almacenarán la propiedad svn:mergeinfo y los servidores anteriores no proporcionarán la información que piden los nuevos clientes.
Find out more about merge tracking from Subversion's Merge tracking documentation.
Importante
The text in the conflict resolver dialogs are provided by the SVN library and might therefore not (yet) be translated as the TortoiseSVN dialogs are. Sorry for that.
Merging does not always go smoothly. Sometimes there is a conflict. TortoiseSVN helps you through this process by showing the merge conflict dialog.
It is likely that some of the changes will have merged smoothly, while other local changes conflict with changes already committed to the repository. All changes which can be merged are merged. The Merge Conflict dialog gives you different ways of handling the lines which are in conflict.
For normal conflicts that happen due to changes in the file content or its properties, the dialog shows buttons which allow you to chose which of the conflicting parts to keep or reject.
- Postpone
Don't deal with the conflict now. Let the merge continue and resolve the conflicts after the merge is done.
- Accept base
This leaves the file as it was, without neither the changes coming from the merge nor the changes you've made in your working copy.
- Accept incoming
This discards all your local changes and uses the file as it arrives from the merge source.
- Reject incoming
This discards all the changes from the merge source and leaves the file with your local edits.
- Accept incoming for conflicts
This discards your local changes where they conflict with the changes from the merge source. But it leaves all your local changes which don't conflict.
- Reject conflicts
This discards changes from the merge source which conflict with your local changes. But it keeps all changes that don't conflict with your local changes.
- Mark as resolved
Marks the conflicts as resolved. This button is disabled until you use the button to edit the conflict manually and save those changes back to the file. Once the changes are saved, the button becomes enabled.
- Editar
Starts the merge editor so you can resolve the conflicts manually. Don't forget to save the file so the button becomes enabled.
If there's a tree conflict, please first see “Conflictos de árbol” about the various types of tree conflicts and how and why they can happen.
To resolve tree conflicts after a merge, a dialog is shown with various options on how to resolve the conflict:
Since there are various possible tree conflict situations, the dialog will show buttons to resolve those depending on the specific conflict. The button texts and labels explain what the option to resolve the conflict does. If you're not sure, either cancel the dialog or use the button to resolve the conflict later.
Cuando desarrolla una nueva característica en una rama separada es una buena idea mantener una política de re-integración cuando la característica está completa. Si se está modificando a la vez trunk (el tronco), puede que encuentre que las diferencias se vuelven significativas según pasa el tiempo, y la fusión se convierte en una pesadilla.
Si la característica es relativamente simple y el desarrollo no llevará mucho tiempo, puede adoptar un camino más simple, que es mantener la rama totalmente separada hasta que la característica se completa, y luego fusionar los cambios de la rama de nuevo en el tronco. En el asistente de fusión esto sería un simple Fusionar un rango de revisiones, donde el rango de revisiones es la rango de revisiones de la rama.
Si la característica va a llevar más tiempo y necesita tener en cuenta los cambios en trunk, entonces necesita mantener las ramas sincronizadas. Esto simplemente significa que periódicamente fusionará el tronco en la rama, para que la rama contenga todos los cambios de la rama además de la nueva característica. El proceso de sincronización utiliza Fusionar un rango de revisiones. Cuando la característica esté completa, podrá fusionarla de nueva en trunk utilizando o bien Reintegrar una rama o Fusionar dos árboles distintos.
Another (fast) way to merge all changes from trunk to the feature branch is to 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 “Opciones de fusión”. The rest is done by TortoiseSVN automatically using merge tracking.