Cómo corrijo "Error de confirmación. El archivo xxx está desactualizado. Ruta xxx no encontrada".

Question

Recientemente me encontré con un problema particularmente pegajoso con respecto a la comisión del resultado de una fusión en subversión. Nuestro servidor Subversion es @ 1.5.0 y mi cliente TortoiseSVN ahora es @ 1.6.1.

Estoy tratando de fusionar una rama de características en mi troncal. La fusión parece funcionar bien; sin embargo, la confirmación falla con el siguiente mensaje de error.

Commit failed (details follow): 
File 
'flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
is out of date 
'/svn/ibis/!svn/wrk/531d459d-80fa-ea46-bfb4-940d79ee6d2e/visualization/trunk/source/flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
path not found 
You have to update your working copy first. 

Mi baúl de trabajo está actualizado. Incluso he comprobado uno nuevo en una carpeta diferente para asegurarme de que no haya ningún cruft local jugando con la fusión. He investigado un poco más sobre esto y creo que parte del problema es un error del usuario. Creo que nuestros problemas son:

1. Tuvimos algunos desarrolladores que se comprometieron a trabajar con un cliente de subversión antes del 1.5 y algunos posteriores. Creo que esto tiene el potencial de corromper la información de fusión.
2. En otras ramas hemos realizado fusiones parciales. Es decir, no siempre realizamos fusiones en la raíz de la rama. Esto fue para facilitar la actualización de los esfuerzos de Flex y .NET dentro de la misma rama.
3. Realizamos fusiones cíclicas (reflexivas) en nuestra rama. Esto se hizo porque teníamos varias ramas paralelas y queríamos actualizar periódicamente nuestra sucursal con el código más reciente en el tronco.

El libro/equipo de Subversion no recomienda explícitamente todas estas cosas. Hemos aprendido nuestra lección y ahora conocemos las mejores prácticas. Sin embargo, primero tenemos que fusionar y comprometer nuestra última sucursal.

¿Cuál es la mejor manera de corregir los problemas que nos encontramos?

¿Sería una solución viable eliminar toda la información de fusión en el enlace y la bifurcación? No. He hecho esto pero no resuelve el error que estoy obteniendo arriba.

Answer 1

He tenido el mismo problema hoy y no he hecho ninguna fusión intermedia, por lo que desde su publicación inicial solo podría aplicarse # 1; sin embargo, he realizado confirmaciones tanto desde un cliente svn en ubuntu como desde tortoisesvn en Windows . Afortunadamente en mi caso no se hicieron cambios en el maletero, así que pude simplemente reemplazar el tronco con la rama. ¿Posiblemente diferentes versiones de svn entonces? Eso es bastante preocupante.

Si usa las funciones svn move/copy/delete aunque no se pierde ningún historial en mi caso - svn movió el trunk y luego svn movió la rama al tronco.

Answer 2

¡Oh muchacho! Esto se ve mal! La única opción que puedo pensar es que la copia de trabajo está corrupta.

Intente eliminar la copia de trabajo, realizar una nueva ejecución y realizar la fusión nuevamente.

Si eso no funciona, registre un error.

Answer 3

No he podido encontrar una solución satisfactoria a este problema; sin embargo, he encontrado una solución insatisfactoria.

He eliminado todos los archivos dentro de trunk y he cometido estos cambios. Luego exporté mi código de sucursal en el enlace troncal, agregué todos los archivos e hice una confirmación grande. Esto tuvo el efecto de que mi tronco imitara mi rama 1: 1 (que es lo que quería de todos modos).

Desafortunadamente, esto crea una gran división ya que el historial de todos los archivos ahora se "pierde". Pero debido a las limitaciones de tiempo, no parecía haber otra opción.

Aún me interesarán las respuestas que puedan tener otras personas, ya que me gustaría saber cuál es la causa raíz y cómo evitarla en el futuro.

Answer 4

Creo que he visto algo similar cuando las carpetas se movieron en el servidor, pero las copias de trabajo aún estaban vinculadas a la estructura de carpetas SVN anterior.No estoy seguro de si alguien movió las cosas en su maletero antes de que tuviera la oportunidad de fusionar la sucursal.

¿Es eso una posibilidad?

Answer 5

Tuve el mismo problema al intentar enviar mi copia de trabajo. Lo que hice fue agregar la carpeta que Subversion reporta como "ruta no encontrada" a la lista de ignorar. Comprometerse (debería tener éxito). Luego agrega la misma carpeta a Subversion. Comprometerse nuevamente.

Answer 6

Esto parece un problema con la propiedad svn:mergeinfo saliendo de wack entre la rama y el tronco.

que nos lleva a las siguientes preguntas (perdona mis instrucciones de línea de comandos como he hecho uso de tortuga mucho):

1. ¿Está la fusión a nivel de la raíz del tronco o el nivel sub carpeta? En mi experiencia, siempre es mejor hacerlo en el nivel raíz, de esta forma todo el tronco cree que se ha fusionado en lugar de simplemente dividirse (esto parece confundir a svn en 1.5.0)

2. Mi siguiente pregunta es ¿Estaba usando el parámetro --reintergrate? Nunca recuerdo cómo llegar a esto en una tortuga, pero cuando vuelves al tronco desde una rama, debes usar este parámetro.

3. ¿Ha fusionado el tronco en la rama antes de que se haya reintegrado? Esto puede ayudar a eliminar conflictos que puede ver cuando se fusiona?

4. ¿Tiene alguna svn:mergeinfo propiedades en la rama que no están en el nivel de raíz? Esto que he encontrado siempre causa problemas. Siempre puede averiguarlo yendo al svn -R pg svn:mergeinfo. A continuación, puede grabar los lugares y las revisiones que estaban debajo de la raíz, si los encuentra relevantes a continuación, pasar a la raíz por svn merge --record-only -r start:end <location> y eliminarlos de los lugares de raíces secundarias con svn pd svn:mergeinfo <location> A continuación, deberá confirmar estos cambios

5. Una vez que tenga todo lo que está hecho, intente fusionar nuevamente.

Answer 7

Lo dudo, pero tal vez ejecutar svn cleanup en su directorio de trabajo ayudará.

Answer 8

Tuve el mismo problema después de fusionar una rama con una tonelada de cambios en mi baúl. Las dos únicas soluciones que pude ver fueron hacer la solución svn move ofrecida por Pacifika o fusionar manualmente los archivos con una herramienta diff. Pero encontré una solución ...

La máquina que no funcionaba ejecutaba el cliente de Subversion 1.6.5. Hice exactamente lo mismo en una máquina con Subversion 1.5.4 y funcionó! En ambas máquinas hice un 1) pago y envío limpio de trunk, 2) svn merge ... y 3) svn commit. Mi servidor es 1.5.x por lo que eso vale.

Espero que esto ayude a alguien.

Answer 9

Acabo de tener un problema similar pero sin ramificarme o fusionarme para causar el problema. Mi solución fue:

• svn exportar mi carpeta de trabajo (incluidos los archivos no versionados) a una carpeta temporal.
• cambie el nombre de la carpeta de trabajo a una copia de seguridad.
• svn checkout the trunk.
• copie todas las carpetas de la carpeta de exportación temporal sobre la nueva carpeta de trabajo.
• svn commit.

Todo parece estar bien ahora.

Answer 10

Estaba obteniendo esto en 1.6.2 servidor, 1.6.8 tortuga. Todo en Windows, no se fusiona en esta rama.

Cambié el nombre de un directorio y de alguna manera (posiblemente debido a AnkhSVN) dos de los archivos dentro del directorio se marcaban como "reemplazado" en lugar de "normal". Hubo algunos cambios menores adicionales a otros archivos dentro del directorio.

Revertir los archivos marcados como reemplazados solucionó el problema.

Answer 11

Acabo de tener este problema, y ​​la causa parecía ser que un directorio había sido marcado como en conflicto. Para solucionar:

svn update 
svn resolved <the directory in conflict> 
svn commit 

Answer 12

me encontré con el mismo problema, vencieron a la cabeza y se encontró que había cambiado el directorio en el represotory de "/" a "/ tronco" y se olvidó de hacer el comando "Switch", en TortoiseSVN!

Answer 13

Tuve un problema similar con el SVN 1.6.5 en Mac 10.6.5, actualicé a SVN 1.6.9 y la confirmación se realizó correctamente.

Answer 14

Sé que esta es una publicación anterior, pero este problema todavía se produce con bastante frecuencia. La manera más simple que he encontrado para resolverlo es cambiar el nombre/eliminar el archivo .svn/all-wcprops en la carpeta afectada, luego ejecutar una actualización y confirmar.

Answer 15

Vaya, me tomó un tiempo resolverlo, ya que estaba usando SVN a través de Eclipse. Al final, lo único que funcionó para mí fue confirmar todos los archivos no afectados, luego (con Eclipse cerrado) renombrar el directorio del proyecto y volver a verificar el proyecto desde SVN. Me alegro de que funcione correctamente ahora!

Answer 16

Aparentemente SVN no es un programa muy confiable. Tuve el mismo problema (usando SVN con Turtoise) y lo resolví guardando el contenido del archivo .cs y luego volviendo 1 revisión. Esto demostró conflictos como este: "< < < < < < < nombre de archivo mis cambios

======= código fusionó desde el repositorio revisión"

aunque no he hecho nada especial (solo una vez retrocedió una revisión).

He reemplazado el contenido de este archivo con el contenido guardado, guardado y luego seleccionado a través de TortoiseSVN → Resuelto. Podría entonces comprometer las modificaciones al repositorio.

Answer 17

También tuve el mismo problema y resolví la misma por el método siguiente

svn resolve --accept=working <FILE/FOLDER NAME> 
svn cleanup 
svn update <FILE/FOLDER NAME> 
svn commit <FILE/FOLDER NAME> -m "Comment" 

Hope esto le ayudará a :)

Answer 18

tuve el mismo problema cuando intentaba cometer un paquete de borrado (que contiene varias clases de Java pero ya no era necesario nada del paquete).

Mi solución/solución con el fin de solucionar el problema:

• que revierte todo el paquete
• suprime el contenido primera
• cometió el contenido eliminado
• finalmente cometió el paquete de borrado de nuevo (y funcionó en la mayoría de los casos :-))

Sin embargo, de vez en cuando no era posible enviar un paquete eliminado (que h no contiene nada)

Mi solución:

• creé una clase ficticia en el paquete
• y después de eso me repiten los pasos mencionados anteriormente

Mi última pista ...

Pero a veces ayuda a sincronizar el paquete/proyecto una vez más y luego todo vuelve a funcionar bien.

Acerca de la configuración de mi:

• Eclipse neón
• SVN Interfaz: JavaHL (JNI) 1.8.13 (r1667537)
• VisualSVN Server Manager Versión: 3.3.1

Tal vez podría ayudar a alguien con uno de mis consejos.

Answer 19

que tenían el mismo problema, no sé cuál es la razón detrás de ella, pero me fijo escribiendo en el terminal

svn update 

y luego cometió y Boom funcionó!