¿Qué debo hacer cuando falla la 'limpieza svn'?

Tengo muchos cambios en una carpeta de trabajo, y algo falló al intentar hacer una actualización.

Ahora cuando publico una 'limpieza de svn' obtengo:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp es un nuevo archivo agregado por otro desarrollador y que fue eliminado en la actualización. No existía en mi carpeta de trabajo antes.

¿Hay algo que pueda hacer para intentar avanzar sin tener que sacar una copia nueva del repositorio?

Aclaración: Gracias por las sugerencias sobre mover el directorio fuera del camino y traer una nueva copia. Sé que es una opción, pero es una que me gustaría evitar, ya que hay muchos cambios anidados en varios directorios (esto debería haber sido una rama ...)

Espero una forma más agresiva de hacer la limpieza, tal vez de alguna manera forzar el archivo SVN está teniendo problemas para volver a un estado conocido (e intenté eliminar la copia de trabajo ... eso no ayudó).

Cuando comenzar de nuevo no es una opción ...

Eliminé el archivo de registro en el .svndirectorio (también eliminé el archivo ofensivo .svn/props-base), hice una limpieza y reanudé mi actualización.

Las cosas han cambiado con SVN 1.7, y la solución popular de eliminar el archivo de registro en el directorio .svn no es factible con el cambio a una implementación de copia de trabajo de la base de datos.

Esto es lo que hice que parecía funcionar:

1. Elimine el directorio .svn para su copia de trabajo.
2. Comience un nuevo pago en un nuevo directorio temporal.
3. Cancele el pago (no queremos esperar a que todo se desarme).
4. Ejecute una limpieza en este pago cancelado.
5. Ahora tenemos un nuevo directorio .svn con una base de datos limpia (aunque no hay / pocos archivos)
6. Copie este .svn en su antiguo directorio de trabajo dañado.
7. Ejecute svn update y debería actualizar su nuevo directorio parcial .svn con su antiguo directorio de trabajo.

Todo eso es un poco confuso, en cuanto al proceso. Esencialmente, lo que estamos haciendo es eliminar el .svn corrupto y luego crear un nuevo .svn para la misma ruta de pago. Luego movemos este nuevo .svn a nuestro antiguo directorio de trabajo y lo actualizamos al repositorio.

Acabo de hacer esto en TSVN y parece funcionar bien y no requiere un pago y descarga completos.

-Jody

Echa un vistazo a

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

Resumen de la corrección del enlace anterior (Gracias a Anuj Varma)

1. Instale el shell de línea de comandos sqlite (sqlite-tools-win32) desde http://www.sqlite.org/download.html

2. sqlite3 .svn/wc.db "select * from work_queue"

SELECT debería mostrarle su carpeta / archivo ofensivo como parte de la cola de trabajo. Lo que debe hacer es eliminar este elemento de la cola de trabajo.

3. sqlite3 .svn/wc.db "delete from work_queue"

Eso es. Ahora, puede ejecutar la limpieza nuevamente, y debería funcionar. O puede continuar directamente con la tarea que estaba haciendo antes de que se le solicite ejecutar la limpieza (agregar un nuevo archivo, etc.)

Si todo lo demás falla:

1. Echa un vistazo a una nueva carpeta.
2. Copie sus archivos modificados.
3. Vuelva a registrarse.
4. Comprima la carpeta anterior en algún lugar (nunca se sabe + la paranoia es buena) antes de eliminarla y usar la nueva.

La última versión (estoy usando 1.9.5) resuelve este problema agregando una opción de "Romper bloqueos" en el menú de limpieza. Solo asegúrese de que esta casilla de verificación esté seleccionada cuando realice la limpieza.

Esta respuesta solo se aplica a las versiones anteriores a 1.7 (gracias @ ŁukaszBachman) .

Subversion almacena su información por carpeta (en .svn), por lo que si solo está tratando con una subcarpeta, no necesita verificar todo el repositorio, solo la carpeta que ha borrado:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

Esto le dará una buena copia de trabajo de la carpeta borked, pero aún tiene sus cambios respaldados en borked_dir.bak. El mismo principio se aplica con Windows / TortoiseSVN.

Si tiene cambios en una carpeta aislada, eche un vistazo a

svn checkout -N borked_dir   # Non-recursive, but deprecated

o

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'

$ ls -la .svn
$ rm -f .svn/lock

Luego

$ svn update

Espero eso ayude

Tuve exactamente el mismo problema. No podía comprometerme, y la limpieza fallaba.

Utilizando un cliente de línea de comandos, pude ver un mensaje de error que indicaba que no podía mover un archivo de .svn/propsa .svn/prop-base.

Miré el archivo específico y descubrí que estaba marcado como de solo lectura. Después de eliminar el atributo de solo lectura, pude limpiar la carpeta y confirmar mis cambios.

Es posible que tenga un problema con dos nombres de archivo que solo difieren en mayúsculas. Si se encontró con este problema, crear otro directorio de copia de trabajo no resuelve el problema.

Los sistemas de archivos actuales de Windows (es decir, basura) simplemente no perciben la diferencia entre Filenamey FILEname. Tienes dos soluciones posibles:

1. Verifique en la plataforma con un sistema de archivos real (basado en Unix), cambie el nombre del archivo y confirme los cambios.
2. Cuando está almacenado en Windows, puede cambiar el nombre de los archivos en el navegador del repositorio Eclipse SVN, que reconoce la diferencia y cambia el nombre del archivo allí.
3. Puede cambiar el nombre de los archivos problemáticos también de forma remota desde cualquier cliente SVN de línea de comandos utilizando svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

Ejecute el svn cleanupcomando en una terminal (si falla desde Eclipse, que fue mi caso):

~/path/to/svn-folder/$ svn cleanup

Intenté diferentes soluciones explicadas aquí, pero ninguna funcionó .

Equipo de acción → La actualización de la cabeza falla:

svn: E155004: Hay elementos de trabajo sin terminar en '/ home / user / path / to / svn-folder'; ejecute 'svn cleanup' primero.

Equipo de acción → La limpieza falla con el mismo error.

Solución que funcionó para mí: ejecute el comando svn cleanup en una terminal .

El comando tuvo éxito.

Entonces Team → Update en Eclipse funcionó nuevamente.

Nota: mi versión SVN es 1.9.3.

También verifique la respuesta de Chris si svn cleanupno funciona.

Intenté hacerlo a svn cleanuptravés de la consola y obtuve un error como:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

Así que creé este archivo manualmente (vacío) y lo hice svn cleanupnuevamente. Esta vez se hizo bien.

Yo tuve el mismo problema. Para mí, la causa fue un conflicto con EasySVN y (TortoiseSVN o simplemente SVN). Tuve actualización automática y confirmación con EasySVN (que no funcionaba).

Cuando apagué esto, no pude limpiar, confirmar o actualizar. Ninguna de las soluciones anteriores funcionó, pero el reinicio sí :)

Acabo de tener este mismo problema en Windows 7 de 64 bits. Ejecuté la consola como administrador y eliminé el directorio .svn del directorio del problema (recibí un error sobre registros o algo, pero lo ignoré). Luego, en el explorador, eliminé el directorio del problema que ya no se mostraba como bajo control de versiones. Luego, ejecuté una actualización y las cosas procedieron como se esperaba.

Si el problema es la distinción entre mayúsculas y minúsculas (que puede ser un problema cuando se registra en una Mac, así como en Windows) y no tiene la opción de verificar en un sistema * nix, lo siguiente debería funcionar. Aquí está el proceso desde el principio:

% svn co http://[domain]/svn/mortgages mortgages

(El pago se produce ... entonces ...)

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

Aquí SVN está tratando de revisar dos archivos con nombres similares que difieren solo por mayúsculas Header_3_noBookmark.gify minúsculas Header_3_nobookmark.gif. Los sistemas de archivos de Mac predeterminan la insensibilidad a mayúsculas y minúsculas de manera que SVN se ahoga en situaciones como esta. Entonces...

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Sin embargo, correr svn cleanupno funciona, como sabemos.

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gifno es el problema aquí ... Simplemente no puede pasar del error anterior al siguiente archivo. Así que eliminé todos los archivos del directorio que no sea .svn, y eliminé el registro SVN. Esto hizo que la limpieza funcionara, de modo que pudiera revisar y cambiar el nombre del archivo ofensivo.

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

Después de esto, pude volver al directorio raíz del proyecto y ejecutar svn uppara ver el resto.

Siempre que tengo problemas similares uso rsync (NB: uso Linux o Mac OS X) para ayudar de esta manera:

# Go to the parent directory
cd dir_above_borked

# Rename corrupted directory
mv borked_dir borked_dir.bak

# Checkout a fresh copy
svn checkout svn://... borked_dir

# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/

# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/

De esa manera, tendrá una salida nueva, pero con los mismos archivos de trabajo. Para mí esto siempre funciona como un encanto.

Me encontré con eso también últimamente. El truco para mí fue después de seleccionar "Limpiar", en el cuadro de diálogo de opciones emergente, marcar "Romper bloqueos" y luego "Aceptar". Se limpió con éxito para mí.

Subclipse se confunde con el comportamiento de bloqueo verdaderamente diabólico de Windows. Unlocker es tu amigo. Esto puede encontrar archivos bloqueados y liberar por la fuerza los bloqueos.

(Antes de intentar mover carpetas y hacer un nuevo pago).

Elimine la carpeta en la que se encuentran los archivos ofensivos: sí, incluso la .svncarpeta, luego haga una svn cleanupen la carpeta superior / principal.

Me enfrenté al mismo problema. Después de algunas búsquedas en Internet encontré el siguiente artículo . Luego me di cuenta de que estaba registrado como un usuario diferente del usuario que había utilizado para configurar SVN, básicamente un problema de permiso.

Cuando enfrento este problema con TortoiseSVN (Windows), voy a Cygwin y ejecuto la ' limpieza de svn ' desde allí; me limpia correctamente, después de lo cual todo funciona desde TortoiseSVN.

Las respuestas aquí no me ayudaron, pero antes de revisar el proyecto nuevamente, cerré y abrí Eclipse (Subversive es mi cliente SVN) y el problema desapareció.

Es posible que no se aplique en todas las situaciones, pero cuando recientemente encontré este problema, mi "solución" fue actualizar el paquete de Subversion en mi sistema. Había estado ejecutando 1.4.algo, y cuando actualicé a la última versión (1.6.6 en mi caso) el pago funcionó.

(Intenté volver a descargarlo, pero un pago a un directorio limpio siempre colgaba en el mismo lugar).

El bloqueo de solo lectura a veces ocurre en unidades de red con Windows. Intente desconectar y volver a conectarlo nuevamente. Luego limpie y actualice.

Después de analizar la mayoría de las soluciones que se citan aquí, seguía recibiendo el error.

El problema era OS X sin distinción entre mayúsculas y minúsculas . Verificar un directorio que tiene dos archivos con el mismo nombre, pero diferentes mayúsculas causa un problema. Por ejemplo, ApproximationTest.java y Approximationtest.java no deberían estar en el mismo directorio. Tan pronto como nos deshacemos de uno de los archivos, el problema desaparece.

Llegué a un problema en el que, después de una actualización, SVN mostró una carpeta en conflicto. Curiosamente, esto solo era visible a través de la línea de comando: TortoiseSVN pensó que todo estaba bien.

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup` svn revert` svn updateysvn resolve estaban todos sin éxito en la fijación del mismo.

Finalmente resolví el problema de la siguiente manera:

• Busque en el directorio .svn "sub_dir"
• Use RC -> Propiedades para desmarcar la marca 'solo lectura' en el archivo de entradas
• Abra el archivo de entradas y elimine la línea "sin terminar ..." y la suma de verificación correspondiente
• Guarde y vuelva a habilitar el indicador de solo lectura
• Repita para el directorio my_dir

Después de eso, todo estuvo bien.

Tenga en cuenta que no tuve ningún cambio local, por lo que no sé si estaría en riesgo si lo hiciera. No utilicé el método de eliminación / actualización sugerido por otros; entré en este estado al intentarlo en el directorio my_dir / sub_dir / sub_sub_dir (que comenzó con los mismos síntomas), por lo que no quería arriesgarme a empeorar las cosas ¡de nuevo!

No del todo sobre el tema, pero tal vez sea útil si alguien se encuentra con esta publicación como lo hice yo.

¡No no no! Si está utilizando SVN 1.7 o superior, ¡el comando de limpieza debería hacer el trabajo!

También hice algunos experimentos y descubrí que la solución (al menos en Eclipse ) estaba ejecutando la limpieza solo para la carpeta especificada en el mensaje de error y no para todo el proyecto.

Lo hice sudo chmod 777 -R .para poder cambiar los permisos. Sinsudo esto, no funcionaría, dándome el mismo error que ejecutar otros comandos.

Ahora puede hacer svn updateo lo que sea, sin tener que desechar todo el directorio y volver a crearlo. Esto es especialmente útil, ya que su IDE o editor de texto ya puede tener ciertas pestañas abiertas o problemas de sincronización. No necesita desechar y reemplazar su directorio de trabajo con este método.

Resolví este problema copiando el directorio .svn de algún colega en el mío y luego actualizando mi copia de trabajo. Fue una solución agradable, rápida y limpia.

Hay algunas sugerencias muy buenas en la respuesta anterior, pero si tiene un problema con TortoiseSVN en Windows (un buen producto, pero ...) siempre recurra a la línea de comandos y haga primero una simple "limpieza de svn".

En muchas circunstancias, el cliente de Windows no ejecutará el comando de limpieza, pero la limpieza funciona bien usando la utilidad de línea de comando SVN.

Si bien se enfrenta a un problema similar, la fusión manual en la vista de sincronización del repositorio ayudó a resolver el problema.

Un nombre de archivo estaba en conflicto con otro y mencionaba claramente el problema. Cambiar el nombre del archivo más nuevo a un nombre diferente lo resolvió.