2010-05-07 11 views
6

Sospecho que tengo mergeinfo corrupto, pero no estoy seguro. ¿Alguien sabe cómo tomaría una determinación y qué recursos hay disponibles para ayudar a solucionar los problemas?¿Cómo puedo determinar si svn: mergeinfo está dañado y cómo lo solucionaría?

Aquí está la cuestión. Mi equipo se movió recientemente a Agile y usa ramas de características (ramas de historia realmente) donde diferentes equipos trabajan en las mismas fuentes al mismo tiempo. A medida que la historia alcanza un alto estado de preparación, el equipo se fusiona con el tronco. Las fusiones demoran días o semanas debido a cambios faltantes, cambios inesperados y conflictos. Estamos hablando de equipos de 5-10 personas y el esfuerzo/abandono parece demasiado alto.

La gente usa el patrón de esta fusión a) Pull - fusionar tronco-a-rama, resolver, prueba, comprometerse b) PUSH - fusionar la rama-a-tronco, resolver, prueba, comprometerse c) Volver a crear la rama (o, por lo general, crea una nueva rama de historia y descarta la antigua, ya que está hecha)

Al final de esto, la rama y el tronco deben estar alineados.

problemas que estamos viendo:

  1. cambios no reportados durante tronco-a-rama fusionar aparecer en posteriores rama-tronco
  2. conflictos sobre propiedades svn: info de fusión durante la fusión
  3. falta el archivo, pero se edita localmente en el nuevo archivo agregado en la rama y se lo envía al tronco
  4. eliminación entrante + local (el archivo eliminado en el tronco y la rama se muestran como conflicto)

(1) No debería estar sucediendo. La extracción de la rama al tronco debe poner los dos en sincronización para todos los cambios que ya están en el tronco. Los cambios en la fusión de rama a tronco son cambios que ocurrieron en el tronco. Entonces en la primera fusión deberían haberse propagado a la rama pero no lo hicieron. Esto apunta a la corrupción en los datos mergeinfo que "ocultarían" los cambios en el tronco.

(2) No debería estar sucediendo. SVN debe administrar los cambios en el seguimiento de fusión. Esto también apunta a la corrupción en los datos mergeinfo

(3) No debería estar sucediendo. Este es un caso de un nuevo archivo agregado en una sucursal. Debería aparecer como un nuevo archivo agregado al tronco. Esto también apunta a la corrupción en los datos de información de fusión.

(4) Creo que esto es un error SVN y que no podemos solucionarlo. Aún así, si este fuera nuestro único problema, estaría contento

Actualmente estamos en el servidor svn 1.5.x con clientes que usan svn 1.6.x y svn + ssh para conectar. Planeamos ir al último y mejor SVN ya que algunas correcciones pueden afectar nuestros problemas.

Aún así, parece que nuestros datos mergeinfo son incorrectos.

  • Merges que no informar todos los cambios
  • Los conflictos en la combinación de las propiedades mergeinfo

Cualquier buenos lugares para mí para empezar a buscar?

+0

SVN 1.6.11 cliente puede ser mi respuesta. Usé el sitio de actualización de wandisco (que oscila) y el infierno de fusión es mucho menos ambicioso –

+0

¿Estás usando la bandera "--reintegrate" para la fusión "push"? El hecho de que tengas un paso de "resolver" después de que me sugiera que no es así. No puedo encontrar documentación específica que indique que las fusiones bidireccionales sin "--reintegrate" no pueden funcionar, pero la mera existencia de "--reintegrate" sugiere que la fusión de svn no está a la altura de la tarea. – slowdog

Respuesta

2

Hice algunos experimentos con la bifurcación/fusión de SVN, y descubrí que hay algunas situaciones en las que la fusión simplemente no funciona; por ejemplo, se sobrescriben los cambios del enlace troncal. Entonces, si sigues usando SVN para ramas características, estarás en un mundo de dolor.

He hecho experimentos similares con git y no he encontrado una manera de obtener una combinación incorrecta. Si la mudanza a git puede ser aceptable para el equipo/la administración, recomiendo usarla.

+0

Oigo eso, pero que los conflictos en las propiedades de mergeinfo parecen indicar un problema más profundo –

+1

Creo que debería aclararme más: traté de romper la fusión en SVN y tuve éxito en mi segundo intento, pero no fui capaz de crear combinación corrupta/incorrecta en Git. Por lo tanto, puede intentar hacer un seguimiento de la causa raíz de los problemas de mergeinfo, o puede usar su tiempo de manera más efectiva y cambiar a un sistema de control de versiones más favorable a sucursales. – chalup

+1

Pasar a git en el marco de tiempo en el que estoy trabajando no es una opción. Por lo tanto, tengo que resolver mi problema en SVN –

2

Tuvimos problemas similares debido a circunstancias similares y las hemos resuelto en gran medida.

La principal es la siguiente:

Si está fusionando en su rama desde el tronco después de la creación de la rama, es necesario tronco, marca con la rama Commit (usando svn fusionar --record-only), de lo contrario, cuando Tratas de reintegrarte de nuevo al tronco. Intenta fusionar el compromiso del tronco con la rama en el tronco.

Obviamente, esto termina volviendo a los cambios del tronco hecha después de la rama más adelante trunk-> cometer, tiende a provocar conflictos masivos (especialmente los conflictos de árboles si ha creado un nuevo archivo o directorio en el tronco), etc.

Así nuestro proceso es que cada línea externa no sincronización en una rama después de haber sido creado (funciona bien para las ramas de corta vida), o para hacer lo siguiente:

  • la rama B del tronco
  • comete en el tronco y la rama
  • reintegrar troncal en rama y confirmar (resolver conflictos pero no hacer cambios, ni siquiera para compilar)
  • inmediatamente hacer una combinación svn --registro solo de la revisión de confirmación troncal a rama
  • solucionar cualquier otro problema con el rama y continuar el desarrollo
  • reintegrar desde la rama al tronco cuando haya terminado.

Encontré: http://www.collab.net/community/subversion/articles/merge-info.html útil mientras resolvía lo que estábamos haciendo mal.

+0

vea también http://stackoverflow.com/questions/3309602/subversion-branch-reintegration-in-v1-6 – Malcolm

Cuestiones relacionadas