svn - working - tortoise cleanup failed

¿Qué debo hacer cuando falla ''svn cleanup''? (30)

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

Ahora cuando emito un ''svn cleanup'' 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 que otro desarrollador agregó y se eliminó en la actualización. No existía en mi carpeta de trabajo antes.

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

Aclaración: gracias por las sugerencias sobre cómo mover el directorio y hacer una copia nueva. 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 realizar la limpieza, quizás alguna forma de forzar el archivo SVN es tener problemas para volver a un estado conocido (y traté de eliminar la copia de trabajo del archivo ... eso no ayudó).

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

También realicé 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.

(Antes de intentar mover carpetas y hacer una nueva compra).

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

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 (obtuve un error sobre los registros o algo así, pero lo ignoré). Luego, en el explorador, eliminé el directorio del problema que ya no se mostraba bajo el control de versiones. Luego, ejecuté una actualización y las cosas procedieron como se esperaba.

Al enfrentar un problema similar, la combinació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 mencionó claramente el problema. Cambiar el nombre del archivo más nuevo a un nombre diferente lo resolvió.

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

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

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

Después de revisar la mayoría de las soluciones que se citan aquí, todavía estaba recibiendo el error.

El tema era OS X insensible a mayúsculas y minúsculas . Verificando un directorio que tiene dos archivos con el mismo nombre, pero diferentes mayúsculas causan un problema. Por ejemplo, ApproximationTest.java y Approximationtest.java no deben estar en el mismo directorio. Tan pronto como nos deshacemos de uno de los archivos, el problema desaparece.

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 de arriba (Gracias a Anuj Varma)

Instale el shell de línea de comandos de sqlite (sqlite-tools-win32) desde http://www.sqlite.org/download.html
sqlite3 .svn/wc.db "select * from work_queue"

El 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.
sqlite3 .svn/wc.db "delete from work_queue"

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

El bloqueo de solo lectura a veces ocurre en unidades de red con Windows. Intenta desconectarlo y reconectarlo de nuevo. Luego limpiar y actualizar.

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

Los sistemas de archivos actuales de Windows (es decir, de mierda) simplemente no asimilan la diferencia entre el Filename y el Filename FILEname . Tienes dos posibles soluciones:

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

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 realice primero una "limpieza svn" simple.

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 comandos SVN.

He intentado realizar una svn cleanup través de la consola y obtuve un error como:

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

Así que creé este archivo manualmente (vacío) e hice svn cleanup nuevamente. Esta vez se hizo bien.

Hice sudo chmod 777 -R . Para poder cambiar los permisos. Sin el sudo , no funcionaría y me daba el mismo error que ejecutar otros comandos.

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

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 al realizar la limpieza.

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

Esto es lo que hice que parecía funcionar:

Elimine el directorio .svn para su copia de trabajo.
Iniciar una nueva compra en un nuevo directorio temporal.
Cancelar el proceso de pago (no queremos esperar a que todo sea derribado).
Ejecutar una limpieza en este pago cancelado.
Ahora tenemos un nuevo directorio .svn con una base de datos limpia (aunque no hay / pocos archivos)
Copie este archivo .svn en su antiguo directorio de trabajo dañado.
Ejecute svn update y debería actualizar su nuevo directorio parcial .svn con su antiguo directorio de trabajo.

Eso es todo un poco confuso, proceso sabio. Esencialmente, lo que estamos haciendo es eliminar el .svn dañado y luego crear un nuevo .svn para la misma ruta de pago. Luego movemos este nuevo archivo .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 una verificación y descarga completas.

-Jody

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ó.

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, marque "Interbloqueo" y luego "Aceptar". Se limpió con éxito para mí.

Me enfrenté al mismo problema. Después de algunas búsquedas en Internet encontramos el siguiente artículo . Luego me di cuenta de que había iniciado sesión como un usuario diferente al usuario que había usado para configurar SVN en un problema de permisos, básicamente.

Me topé con un problema en el que, después de una actualización, SVN mostraba una carpeta en conflicto. Extrañamente, 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 update y svn resolve lograron solucionar este problema.

Eventualmente resolví el problema de la siguiente manera:

Busque en el directorio .svn para "subdirectorio"
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 comprobación correspondiente
Guarda y vuelve a habilitar el indicador de solo lectura
Repetir para el directorio my_dir

Después de eso, todo estaba bien.

Tenga en cuenta que no tuve ningún cambio local, así 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 quise arriesgarme a empeorar las cosas ¡otra vez!

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

Puede que no se aplique en todas las situaciones, pero cuando encontré este problema recientemente, 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) la verificación funcionó.

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

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

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

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

(El pago se produce ... 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)

Aquí, SVN está intentando verificar dos archivos con nombres similares que difieren solo por mayúsculas y minúsculas: Header_3_noBookmark.gif y Header_3_nobookmark.gif . Los sistemas de archivos de Mac se ajustan de forma predeterminada a la insensibilidad de mayúsculas y minúsculas de una manera que hace que SVN se ahogue en situaciones como esta. Asi que...

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

Sin embargo, ejecutar svn cleanup no funciona, como sabemos.

% 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

spacer.gif no es el problema aquí ... Simplemente no puede pasar del error anterior al siguiente archivo. Así que borré 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.

# 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/

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

Si todo lo demás falla:

Echa un vistazo a una nueva carpeta.
Copia tus archivos modificados encima.
Compruebe de nuevo en.
Guarda la carpeta antigua en algún lugar (nunca se sabe + la paranoia es buena) antes de eliminarla y usar la nueva.

Siempre que tengo problemas similares, uso rsync (NB: uso Linux o Mac OS X) para ayudar así:

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

De esa manera, tendrá un nuevo checkout, pero con los mismos archivos de trabajo. Para mí esto siempre funciona como un amuleto.

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.

Tuve exactamente el mismo problema. No pude comprometerme, y la limpieza fallaría.

Al usar un cliente de línea de comandos pude ver un mensaje de error que indicaba que no se podía mover un archivo de .svn/props a .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.

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 cometer con EasySVN (que no estaba funcionando).

Cuando desactivé esto, no pude limpiar, confirmar o actualizar. Ninguna de las soluciones anteriores funcionó, pero reinició :)

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 revisar todo el repositorio, solo la carpeta que contiene el borked:

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 tendrá 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 la

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

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

TL; DR

Ejecuta el comando svn cleanup en un terminal:

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

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

Equipo de acción → La actualización para encabezar falla:

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

Equipo de acción → La limpieza falla con el mismo error.
Nota: mi versión SVN es 1.9.3.

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

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

El comando tuvo éxito. Entonces Team → Update en Eclipse funcionó de nuevo.

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

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

Entonces

$ svn update

Espero eso ayude