Subversion mergeinfo arruinado después de la fusión de tronco a twig

Estoy probando versiones recientes de Subversion, tanto el cliente de línea de command SVN como TortoiseSVN. (Hasta este momento he estado usando principalmente versiones anteriores a la introducción de las properties de mergeinfo y el –innovar el interruptor de fusión.)

He hecho el Google obligatorio, pero tengo un Google-fu realmente malo o lo que sigue es en realidad un problema que nadie ha explicado y / o resuelto exhaustivamente. Me resulta un tanto desconcertante, ya que aquí hay numerosos informes sobre el problema, no hay problema para encontrar esos informes. También encuentro otras discusiones sobre los puntales de mergeinfo, pero nada que realmente concuerde yy explica / resuelve lo que experimento.

Agradecería cualquier ayuda para mejorar mi Google-fu o entender qué sucede y qué hacer al respecto.

Aquí va:

  1. Tengo un tronco (y una copy de trabajo BASED)

  2. Creo una twig (y una copy de trabajo BASEd en ella)

  3. Hago algunos cambios en el WC del tronco y comprometo

  4. Trabajo un poco en el WC de la twig y me comprometo

  5. Ahora fusiono el trabajo en el tronco con el WC de mi sucursal, resolviendo cualquier conflicto.

Hasta ahora todo va según lo esperado, pero cuando trato de confirmar el resultado de la fusión, recibo un post que indica que la copy de trabajo está desactualizada y necesita actualizarse primero.

Esto no tiene sentido. El WC estaba actualizado inmediatamente antes de la fusión, y el objective de la fusión era el WC. Así que nada debería haberse cambiado en el repository.

Al profundizar, parece que el problema es la propiedad mergeinfo como tal.

No tengo problemas para enviar los files modificados de forma individual, pero después de eso, el WC todavía está sucio / no totalmente comprometido y todavía no puedo confirmar porque el WC no está actualizado. Por lo tanto, parece que Subversion ha estado tocando la propiedad mergeinfo tanto en el repository como en el WC.

En el caso de que repita esta investigación, no tengo problemas para actualizar el WC primero y luego comprometerme. Pero no estoy seguro de que este sea siempre el caso, u otras variantes de este fenómeno serán más difíciles de resolver. Tampoco espero tratar de "explicar" esto a usuarios de Subversion cercanos, que no tienen esta como una de sus "herramientas principales".

He probado esto de aquí para allá durante varios años y creo que este problema ha estado presente desde la introducción de mergeinfo y la funcionalidad de integración (1.5?) Hasta ahora. ¿Puede ser así? Y todavía no está dirigido?

Mis testings actuales se han realizado tanto con el cliente de línea de command (instalado desde CollabNetSubversion-client-1.6.17-4.win32.exe) como con TortoiseSVN (TortoiseSVN-1.6.16.21511-win32-svn-1.6.17.msi), y Obtuve los mismos resultados.

He estado usando Subversion durante muchos años y me he descrito como un "usuario avanzado". Aún así, con este problema me quedo con los pantalones bajados ..

Apéndice

Estos son los pasos con los que puedo reproducir el problema:

  1. Cree un repository en "C: \ Documents and Settings \ johndoe \ My Documents \ SVN \ Repo"

  2. Con el browser Repo, cree "file: /// C: / Documents and Settings / johndoe / My Documents / SVN / Repo / Trunk" (r1)

  3. Con el browser Repo, cree "file: /// C: / Documents and Settings / johndoe / My Documents / SVN / Repo / Branches" (r2)

  4. Cree una copy de trabajo del enlace troncal en "C: \ Documents and Settings \ johndoe \ Mis documentos \ SVN \ WCs \ Trunk" (sin nueva revisión)

  5. En el tronco, crea un file de text test.txt, agrégalo y confirma (r3)

  6. Cree una twig del tronco en "file: /// C: / Documents and Settings / johndoe / My Documents / SVN / Repo / Branches / Branch1" (r4)

  7. Cree una copy de trabajo de esta twig en "C: \ Documents and Settings \ johndoe \ Mis documentos \ SVN \ WCs \ Branch1" (sin nueva revisión)

  8. En la copy de trabajo BASEd en Trunk, agregue una línea de text para test.txt y commit (r5)

  9. En la copy de trabajo BASEd en Branch1, agregue una línea de text a test.txt y commit (r6)

  10. Fusiona el tronco con la twig. Haga clic derecho en "C: \ Documents and Settings \ johndoe \ Mis documentos \ SVN \ WCs \ Branch1", Tortoise SVN, Merge. Fusionar tipo "Fusionar un range de revisiones", URL para combinar desde: "file: /// C: / Documentos y configuraciones / johndoe / Mis documentos / SVN / Repo / Troncal", Revisiones para fusionar:, Copia de trabajo: "C : \ Documents and Settings \ johndoe \ Mis documentos \ SVN \ WCs \ Branch1 ", todo lo demás por defecto. En el dialog Resolve Conflict "Resolver todo más tarde". (no hay una nueva revisión)

  11. Resuelve el conflicto Haga clic derecho en el file, Tortoise SVN, Editar Conflictos. En TortoiseMerge, marque y select "El suyo antes que el mío", click "Marcar como resuelto", guarde y salga. (no hay una nueva revisión).

  12. Intenta comprometer los cambios en Branch1.

En este punto, recibo un post

Commit C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1 Commit failed (details follow): Directory '/Branches/Branch1' is outof date You have to update your working copy first. 

Esto no tiene sentido para mí: antes de la fusión, la copy de trabajo estaba actualizada. Después de eso no se han creado nuevas revisiones (repo HEAD sigue siendo r6), y ahora mi copy de trabajo no está actualizada.

Investigando aún más, parece que una actualización del WC para Branch1 tan pronto como entre los pasos 9 y 10 hace que el problema desaparezca. De nuevo, esto no tiene sentido para mí: i) En el dialog al final de la actualización, nada se informa como realmente actualizado, y ii) La única cosa cambiada en la twig ya está comprometida. Entonces, en mi opinión, el WC es "limpio" (nada comprometido) y actualizado (nada en el repository para contribuir al WC).

Lo único que realmente hace la actualización es cambiar la BASE de la copy de trabajo de Branch1 de r4 a r6. Esto es de alguna manera significativo, pero en este momento mi cabeza me da vueltas demasiado para aclarar los detalles.

Agradecería cualquier idea nueva que me haga ver lo que sucede aquí.

Addendum 2

Tratando de aclarar mi pensamiento: Las preguntas frecuentes a las que se apuntó dicen

Cuando Subversion se compromete, el cliente solo supera los numbers de revisión de los nodos que toca la confirmación, no todos los nodos en la copy de trabajo. Esto significa que en una única copy de trabajo, los files y subdirectorys pueden estar en diferentes revisiones, dependiendo de la última vez que los haya comprometido. En ciertas operaciones (por ejemplo, modificaciones de propiedad de directory), si el repository tiene una versión más reciente del nodo, se rechazará la confirmación para evitar la pérdida de datos.

Interpreto "el nodo" como "file: /// C: / Documents and Settings / johndoe / My Documents / SVN / Repo / Branches / Branch1" en mi caso. Según lo veo, el repository no tiene "una versión más reciente de [ese] nodo". En general, el HEAD del repos es r6, pero la versión más reciente del nodo en cuestión es r4.

No tiene nada que ver con el stackr mergeinfo, pero con el hecho de que se modificó una propiedad (ok, en este caso, la propiedad de información de fusión) en una carpeta .

Ver la input de preguntas frecuentes sobre esto.

No estás solo: veo esto también. No parece ser algo que causa problemas, y parece exhibirse cuando intentas asignar properties a una carpeta que tiene hijos de una revisión posterior. Entonces, hay una versión posterior de su nodo en algún sentido: la versión de la revisión posterior tiene nodos secundarios diferentes a la versión de la revisión anterior. No he observado el código, pero imagino que estos niños están almacenados en el nodo de una manera similar a la forma en que se almacenan las properties.

Después de hacer algunos experimentos, la respuesta de Stefans tiene más sentido. Tiene toda la razón al decir que esto no es específico de la propiedad mergeinfo. Lo verifiqué poniendo mi propiedad arbitraria en la carpeta superior de mi copy de trabajo de la sucursal.

Todavía tengo curiosidad por la formulación

En ciertas operaciones (por ejemplo, modificaciones de propiedad de directory), si el repository tiene una versión más reciente del nodo, se rechazará la confirmación para evitar la pérdida de datos. Comenzando en el momento de la bifurcación (la twig ha producido r4) I

  • cree un WC de esta twig (tanto el directory superior como el único en ese directory están actualizados y limpios (no hay cambios sin compromiso) en este punto.
  • edite el file y confirme (HEAD es r5, COMMITTED del directory es r4, confirmado por el file es r5)
  • poner una propiedad en el directory en el WC

Y nuevamente, cuando bash comprometerme, obtengo el error. El problema es con el nodo de carpeta.

SVN STAT produce:

 C:\SVN T2\WCs\Branch1>svn stat M . 

Un DIFF muestra exactamente un cambio en la carpeta (la propiedad agregada):

 C:\SVN T2\WCs\Branch1>svn diff Property changes on: . ___________________________________________________________________ Added: je:dummy + Dummy value 

Finalmente, INFO dice:

 C:\SVN T2\WCs\Branch1>svn info Path: . URL: file:///C:/SVN%20T2/Repo/Branches/Branch1 Repository Root: file:///C:/SVN%20T2/Repo Repository UUID: 009c3a97-e14f-234a-92e9-d30c537e29f9 Revision: 4 Node Kind: directory Schedule: normal Last Changed Author: SEEKDAHLJ Last Changed Rev: 4 Last Changed Date: 2011-07-27 09:26:53 +0200 (on, 27 jul 2011) 

Entonces mi BASE del directory es r4, HEAD también es r4, y tengo un cambio sin connection. No puedo ver qué conflicto podría haber.

Si alguien puede arrojar algo de luz sobre esto, sería muy agradecido. ¿Qué me estoy perdiendo?

Experimentando aún más, haciendo una secuencia similar pero agregando un file al directory en lugar de agregar una propiedad, no hay tal conflicto.

Entonces, sí, esto está relacionado con las properties en particular, y la pregunta que me queda es si alguien podría describir un escenario donde realmente ocurre un conflicto.