¿Cómo se determina si SVN: mergeinfo es corrupto y ¿cómo puedo solucionarlo?

Question

sospecho que tengo mergeinfo corruptos, pero no estoy seguro. ¿Alguien sabe cómo me gustaría hacer una determinación y qué recursos están ahí para ayudar a solucionar problemas?

Aquí está el problema. Mi equipo se trasladó recientemente a ágil y utiliza la función de ramas (ramas de la historia realmente) donde los diferentes equipos de trabajo en las mismas fuentes simultáneamente. A medida que la historia alcanza un alto grado de preparación el equipo se fusiona en el tronco. Las fusiones están tomando días o semanas debido a los cambios que faltan, los cambios inesperados y conflictos. Estamos hablando de equipos de 5-10 personas y el esfuerzo / rotación parece demasiado alto.

La gente usa el patrón de esta fusión a) Pull - combinación de línea externa a-rama, determinación, prueba, comprometerse b) PUSH - fusión rama-a-tronco, determinación, prueba, comprometerse c) Volver a crear la rama (o por lo general crear nueva rama historia y soltar de edad, ya que está hecho)

Al final de esta la rama y el tronco debe estar en la alineación.

Los problemas que estamos viendo:

1. No se notifiquen los cambios durante la fusión de línea externa a la rama aparece en la rama posterior a línea externa
2. conflictos sobre propiedades svn: info de fusión durante la fusión
3. archivo que falta, pero edición local el nuevo archivo añadido en rama y empujado al tronco
4. locales de eliminación entrante + (archivo borrado en el tronco y la rama de espectáculos como los conflictos)

(1) ¿No debería estar sucediendo. El tirón de rama en tronco debe poner los dos en sincronía para todos los cambios que ya están en el tronco. Los cambios en la combinación de rama-tronco son los cambios que ocurrieron en el tronco. Así, en la primera fusión que deberían haber propagado en rama, pero no lo hizo. Esto apunta a la corrupción en los datos mergeinfo lo que “ocultar” los cambios del tronco.

(2) no debería estar sucediendo. SVN debe ser la gestión de los cambios en el registro de fusiones. 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 la rama. Debe aparecer como un nuevo archivo añadido al tronco. Esto también apunta a la corrupción en los datos de información de combinación.

(4) Creo que esto es un error SVN y que no podemos solucionar este problema. Aún si esto fuera nuestro único problema sería feliz

Actualmente estamos en el servidor SVN 1.5.x con los clientes utilizando svn 1.6.x y SVN + SSH para la conexión. Tenemos la intención de subir a la última y más grande SVN ya algunas correcciones pueden afectar nuestros problemas.

Sin embargo, parece seguro como nuestros datos mergeinfo está mal.

• Merges que no reportan todos los cambios
• Los conflictos en fusión de propiedades mergeinfo

Cualquier lugares buenos para mí para empezar a buscar?

Answer 1

Lo hice algunos experimentos con SVN ramificación / fusión, y descubrí que hay algunas situaciones en las que la fusión no funciona - por ejemplo, cambios de tronco se sobreescriben. Así que si usted sigue usando SVN para las ramas de características, que estará en mundo de dolor.

Hice experimentos similares con Git y no he encontrado una manera de conseguir de combinación incorrecta. Si se mueve a git podría ser aceptable por el equipo / gestión, recomiendo encarecidamente el uso de la misma.

Answer 2

Hemos tenido problemas similares debido a circunstancias similares y en gran medida los hemos solucionado.

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 merge --record-only), de lo contrario cuando intenta reintegrarse al tronco que trata de fusionar el commit del tronco a la parte posterior rama en el tronco.

Esto, obviamente, 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í que nuestro proceso es el tronco, o bien nunca sincronización en una rama después de haber sido creado (bien trabaja para sucursales de breve duración), o para hacer lo siguiente:

• b rama del tronco
• commit en el tronco y la rama
• tronco de reintegración en rama y confirma (la resolución de conflictos, pero de otro modo hacer ningún cambio, incluso la realización)
• inmediatamente hacer un svn merge --record sólo del tronco-a-rama revisión de confirmación
• solucionar cualquier otro problema con la rama y continuar el desarrollo
• de reintegración de la rama en el tronco cuando está hecho.

He encontrado: http://www.collab.net/community /subversion/articles/merge-info.html útiles, mientras que la elaboración de lo que estábamos haciendo mal.