2010-05-12 19 views
16

Cuando funciona el SVN con el seguimiento de fusión, es realmente agradable, me encanta. Pero sigue enredado. Estamos usando TortoiseSVN. Continuamente recibimos el siguiente mensaje:¿Qué estoy haciendo mal con la fusión de SVN?

Error: Reintegrate can only be used if revisions 1234 through 2345 were previously merged from /Trunk to the reintegrate source, but this is not the case

Como referencia, este es el método que estamos utilizando:

  1. crear una rama
  2. se desarrollan en la rama
  3. Ocasionalmente combinar un intervalo de revisiones del Tronco a la Rama
  4. Cuando la rama es estable, Reintegrar una rama de la rama al tronco
  5. Eliminar la rama

I fusionar un rango de revisiones desde el tronco a la rama (dejando la gama en blanco, por lo que debe ser todas las revisiones) justo antes de la reintegre la operación, por lo que la rama debe estar sincronizada correctamente con el tronco.

En este momento, el Troncal tiene múltiples propiedades de seguimiento de fusión SVN asociadas. ¿Deberia? ¿O debería un Reintegrate no agregar ninguna información de seguimiento de fusión?

¿Hay algún problema con nuestro proceso? Esto hace que SVN no se pueda utilizar: 1 de cada 3 reintegraciones me obliga a bucear y hackear la información de seguimiento de fusión.

+0

puede evitar muchos de esta fusionar el infierno mediante el uso de una herramienta automatizada para fusionar (lo hará por usted en segundo plano) buscar en Google "svn auto-fusión" – Jas

Respuesta

3

Bunny hopping podría ser la solución.

Básicamente, en lugar de combinar de forma continua los cambios del tronco en una sola rama (branches/foo, vamos a llamarlo), cuando se quiere tirar de los cambios desde el tronco:

  1. Copiar el tronco a una nueva rama (branches/foo2).
  2. Combina los cambios de la rama anterior (fusiona branches/foo en branches/foo2).
  3. Eliminar la rama anterior (eliminar branches/foo).
+2

Voy a investigar eso, pero parece bastante desagradable. Si se trata de ramas difíciles de administrar, el valor de SVN parece ser bastante bajo. – RandomUsername

+1

Por eso uso git en casa, y pronto (cuando la integración de Windows es un poco mejor) en el trabajo. :-P –

3

Tu problema es que estás intentando usar Reintegrate merge en una rama que ha sido 'corrompida' por tener una 'media fusión' ya hecha en ella. Mi consejo es ignorar la reintegración y atenerse a la fusión de revisión si este es su flujo de trabajo.

Sin embargo, la gran razón por la que obtienes errores es porque SVN está realizando algunos controles por ti. En este caso, si la combinación tiene información de merge adicional de archivos individuales allí, entonces svn arrojará un tambaleante y evitará que se fusione, principalmente porque este caso puede producir errores que posiblemente no notará. Esto se llama subtree merge en la terminología svn reintegrate (lea la sección Reintegrar a la Rescate, particularmente la controvertida verificación de reintegración al final).

Puede detener la grabación de mergeinfo cuando realiza fusiones intermedias, o simplemente deja la rama sola hasta que esté lista; a continuación, la fusión recogerá los cambios realizados en el enlace troncal. Creo que también puedes pasar por alto esta comprobación al fusionar todo el tronco con las ramas, no con los archivos individuales, manteniendo así mergeinfo seguro para la reintegración final al final.

EDIT:

@randomusername: Creo (nunca parecía demasiado estrecha) en movimiento es que caiga en la trampa 'fusión parcial'. Una característica interesante de SVN es que puedes hacer un pago escaso: solo obtener una copia parcial de un árbol. Cuando fusionas un árbol parcial en, SVN no puede decir que todo se fusionó, ya que obviamente no lo era, por lo que registra Mergeinfo de forma ligeramente diferente. Esto no ayuda con la reintegración ya que la reintegración tiene que fusionar todo de vuelta al tronco, y ahora se encuentra que algunos bits se modificaron sin fusionarse, por lo que se queja. Un movimiento parece ser lo mismo: una parte del árbol ramificado ahora aparece de manera diferente en la información de merge de lo que espera. No me molestaría en reintegrarme, y me quedaré con la combinación de rango de revisión normal. Es una buena idea, pero trata de ser demasiadas cosas para demasiados usuarios en demasiadas circunstancias diferentes.

El

+0

Gracias por la respuesta. Tengo una mejor comprensión de la fusión de subárboles ahora, pero no sabía por qué la estábamos viendo; solo nos fusionábamos en el nivel superior, nunca en un subdirectorio o nivel de archivo. Sin embargo, estábamos realizando algunos cambios de nombre, que creo que es el culpable. La página a la que vinculó señala esto, pero deja abiertas sus razones para hacer este extraño comportamiento. Me siento mucho mejor con SVN ahora que la rareza es al menos determinable (el cambio de nombre parece defectuoso) y reparable (elimina la información de fusión de los archivos renombrados). – RandomUsername

9

Este problema a veces ocurre cuando una combinación parial se ha hecho desde el tronco para ramificarse en el pasado. Una combinación parcial es cuando realiza una fusión en todo el árbol, pero solo compromete una parte. Esto le proporcionará archivos en su árbol que tienen datos mergeinfo que no están sincronizados con el resto del árbol.

El mensaje de error --reintegrate anterior debe listar los archivos con los que svn tiene un problema (al menos lo hace en svn 1.6).

Puede:

  1. unir los archivos manualmente el problema desde el tronco a la rama, utilizando el rango del mensaje de error. Nota: debe restar 1 desde el inicio del rango, por lo que el comando que había corrido sería:

    cd <directory of problem file in branch working copy> 
    svn merge -r1233:2345 <url of file in trunk> 
    svn commit 
    

    o

  2. Si está seguro de que el contenido de los archivos en su rama es correcto y lo que desea es marcar los archivos que se fusionó, podría utilizar la bandera --record-only a svn merge:

    cd <directory of problem file in branch working copy> 
    svn merge --record-only -r1233:2345 <url of file in trunk> 
    svn commit 
    

(creo que se puede utilizar --record-only en todo el árbol, pero no lo he probado y debe estar absolutamente seguro de que no hay fusiones reales que deban venir de la cajuela)

+0

Gracias, "--record-only" funcionó de maravillas para mí. – NSAlexC

0

Sospecho que no está siguiendo las instrucciones de fusión correctamente :

"Ahora, use svn merge con la opción --reintegrate para replicar los cambios de su rama nuevamente en la línea troncal. Necesitará una copia de trabajo de/trunk. Puede obtener una haciendo una comprobación de svn, extrayendo una vieja copia de trabajo de troncal desde algún lugar de su disco, o usando el interruptor svn (consulte la sección llamada "Travesing Branches"). Su copia de trabajo de troncal no puede tener ninguna edición local ni contener una combinación de revisiones (consulte la sección llamada "Copias de trabajo de revisión mixta"). Si bien estas suelen ser las mejores prácticas para fusionarse de todos modos, son necesarias cuando se utiliza la opción --reintegrate.

Una vez que tenga una copia de trabajo limpia del tronco, ya está listo para fusionar su rama de nuevo en él:".

tengo algunos problemas con la fusión de

Cuestiones relacionadas