Copia de trabajo XXX bloqueada y error de limpieza en SVN

Me sale este error cuando hago un svn update:

Copia de trabajo XXXXXXXX bloqueada Ejecute el comando "Limpieza"

Cuando ejecuto la limpieza, me sale

La limpieza no pudo procesar las siguientes rutas: XXXXXXXX

¿Cómo salgo de este ciclo?

Un enfoque sería:

1. Copie los elementos editados a otra ubicación.
2. Elimine la carpeta que contiene la ruta del problema.
3. Actualice la carpeta que contiene a través de Subversion.
4. Copie sus archivos o combine los cambios según sea necesario.
5. Cometer

Otra opción sería eliminar la carpeta de nivel superior y volver a pagar. Sin embargo, espero que no llegue a eso.

Para mí, el truco consistía en ejecutar svn cleanupen la parte superior de mi copia de trabajo, no en la carpeta donde había estado trabajando todo el tiempo antes de que ocurriera el problema.

Mire en su .svncarpeta, habrá un archivo llamado lock. Elimine ese archivo y podrá actualizar. Puede haber más archivos de bloqueo en el .svndirectorio de cada subdirectorio. Necesitarán eliminar también. Esto podría hacerse como un lote simplemente desde la línea de comandos con, por ejemplo,

find . -name 'lock' -exec rm -v {} \;

Tenga en cuenta que está editando manualmente archivos en la .svncarpeta. Han sido puestos allí por una razón. Esa razón podría ser un error, pero si no, podría estar dañando su copia local.

FUENTE: http://www.svnforum.org/2017/viewtopic.php?p=6068

En mi caso, lo resolví eliminando manualmente un registro en el registro de bloqueo de archivo ".svn \ wc" de SQLite en la tabla WC_LOCK.

Abrí el archivo "WC" con el editor SQLite y ejecuté

delete from WC_LOCK

Después del comentario de eakkas , es posible que también deba eliminar todas las entradas de la WORK_QUEUEtabla.

La forma más fácil que nunca:

1. Vaya al directorio principal (carpeta) del proyecto .
2. Pres clic derecho
3. Presione TortoiseSVN y luego presione Limpiar ...
4. El diálogo de limpieza aparecerá automáticamente
5. Seleccione Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays,Include externals
6. Pres OK

Hiciste tu trabajo con éxito.

Verifique las capturas de pantalla para su referencia.

Primer paso:

Segundo paso: habilite la opción Bloquear bloqueo (segunda casilla en la ventana emergente de limpieza)

Espero que esto te ayude mucho.

Un colega en el trabajo ve constantemente este mensaje, y para él es porque eliminó un directorio bajo el control de versión de SVN sin eliminarlo de SVN, y luego creó un nuevo directorio en su lugar, no bajo control de versión, con el mismo nombre.

Si este es tu problema ...:

Hay diferentes formas de solucionarlo, dependiendo de cómo / por qué se reemplazó el directorio.

De cualquier manera, es probable que necesite:

A) Cambie el nombre del directorio existente a un nombre temporal

B) Realice una reversión de SVN para recuperar el directorio eliminado del sistema de archivos, pero no del SVN

A partir de ahí, ya sea

A) Copie los archivos relevantes en el directorio que fue eliminado

B) Si tuviera un cambio significativo de los contenidos en el directorio, hacer un SVN borrar en el original, cometió, y cambiar el nombre de su nuevo directorio de volver al nombre deseado, seguido de un SVN añadir a conseguir que uno bajo el control de versiones.

Para mí, ninguna de las soluciones anteriores funcionó. Encontré una solución rompiendo las cerraduras. Cuando realicé la limpieza de svn, seleccioné "Romper bloqueos" junto con "Limpiar el estado de la copia de trabajo".

Este me funcionó.

1. Ve a la carpeta raíz,
2. Clic derecho y limpieza
3. Verifica todas las opciones disponibles
4. Presiona OK

Después de la limpieza, le permitirá actualizar a la última versión.

Para mí, en realidad fue culpa de Tortuga, más o menos. Tortoise simplemente se quejó de "no se puede limpiar, ejecutar la limpieza", pero cuando ejecuté la línea de comando (svn cleanup), me dijo claramente que no podía eliminar algunos archivos que estaban en uso, la solución para la cual era obvia. Una vez que cerré Visual Studio (que mantenía los archivos abiertos), la limpieza funcionó bien.

Otros programas también pueden mantener abiertos los archivos en el repositorio que causa este problema. Excel manteniendo un xls abierto fue un culpable en otro caso, por lo que puede ser conveniente cerrar todos los programas que puedan estar usando algo en el repositorio o incluso reiniciar para forzar el cierre de los programas y luego intentar nuevamente la limpieza.

Tuve este problema porque las carpetas externas no quieren vincularse a una carpeta existente. Si agrega una línea de propiedad svn: externals donde el destino es una carpeta existente (versionada o no versionada), obtendrá el error de Bloqueo de copia SVN Woring. Aquí una limpieza también le dirá que todo está bien, pero aún así la actualización no funcionará.

Solución: elimine la carpeta problemática del repositorio y realice una actualización en la carpeta raíz donde se establece la propiedad svn: externals. Esto creará la carpeta y todo estará bien nuevamente.

Este problema surgió para mí porque svn: externals para archivos requiere que la carpeta de destino esté controlada por la versión. Después de notar que esto no funciona en diferentes repositorios, cambié de archivos externos a carpetas externas y me metí en este lío.

La forma más fácil de hacer esto es mostrar carpetas ocultas y luego abrir la carpeta .SVN. Debería ver un archivo de cero KB llamado "bloqueo" al eliminar esto solucionará el problema

Me encontré exactamente el mismo problema usando SVN 1.7 y ninguna de las correcciones mencionadas anteriormente funcionó.

Ante todo, asegúrese de hacer una copia de seguridad de todo su contenido editado.

Después de pasar un par de horas (no volví a descargar todo ya que mi rama tiene más de 6 gb de tamaño), descubrí que hay un archivo db llamado "wc" en la carpeta .svn de su rama.

Abra el archivo db con cualquier administrador de db (utilicé el complemento de administrador sqlite de firefox) y navegue a la tabla WC_LOCK. Esta tabla tendrá las entradas para los bloqueos adquiridos. Elimine los registros de la tabla y ya está :)

Cuando tengo este problema, encuentro que ejecutar el comando de limpieza directamente en la ruta del problema generalmente parece funcionar. Luego ejecutaré la limpieza desde la raíz de trabajo nuevamente, y se quejará de algún otro directorio. y solo repito hasta que deje de quejarse.

Si está en una máquina con Windows, vea el repositorio a través de un navegador y puede ver dos archivos con el mismo nombre de archivo pero con diferentes casos. Subversion distingue entre mayúsculas y minúsculas y Windows no lo es, por lo que puede obtener un bloqueo cuando Windows piensa que está tirando hacia abajo el mismo archivo y Subversion no. Elimine los nombres de archivos duplicados en el repositorio e intente nuevamente.

Lo hice simplemente creando una nueva carpeta, revisando el proyecto, copiando los archivos actualizados a la nueva carpeta.

Fue arreglado con un nuevo pago y envío.

¿Está utilizando TortoiseSVN y acaba de actualizar? He tenido ese problema antes al pasar de 1.4 a 1.5 y no reiniciar. (Intenta reiniciar).

La razón por la que necesita reiniciar es porque el archivo de caché se vuelve completamente original.

De lo contrario, para continuar, exporte esa copia de trabajo a una nueva carpeta (no copie las carpetas ocultas .svn), vuelva a pagar el proyecto y mueva todo su código de nuevo, luego continúe con su confirmación.

simplemente elimine las carpetas .svn, luego ejecute una limpieza en el directorio principal. ¡¡Funciona perfectamente!!

En Versiones bajo Mac OS: Acción -> Limpiar bloqueos de copia de trabajo en ...

A menudo tengo ese problema. Mi patrón que causa problemas de limpieza.

1. Abro el archivo de imagen en el visor.
2. Borro el archivo / carpeta de imagen.
3. Estoy intentando comprometer / actualizar

Cerrar el visor de imágenes donde se abre el archivo eliminado resuelve el problema. Quizás otro software pueda bloquear la limpieza de la misma manera.

En general. Creo que reiniciar la computadora puede ayudar en tales casos.

SVN normalmente actualiza su estructura interna (.svn / prop-base) de los archivos en una carpeta antes de que los archivos reales se obtengan del repositorio. Una vez que se recuperan los archivos, esto se borrará. Con frecuencia, se produce el error porque la "actualización" falló o se canceló prematuramente durante el progreso de la actualización.

1. Verifique que los archivos estén listados en el directorio .svn / prop-base
2. Eliminar cualquier archivo que no esté debajo de la carpeta
3. Limpiar
4. Actualizar

Ahora la actualización debería funcionar.

Tuve el mismo problema porque exporté una carpeta en una carpeta controlada por versión. Tuve que eliminar la carpeta de TortoiseSVN, luego eliminar la carpeta del sistema de archivos (TortoiseSVN no le gustan las subcarpetas no versionadas ... ¿por qué no ???)

Iniciar búsqueda ... Bloquear ... Seleccione todos los archivos enumerados y elimínelos ... arreglados

lo siguiente debe hacer:

estado de svn | grep ". L" | sed 's /.* (. *) $ / \ 1 /' | awk '{longitud de impresión ($ 1), $ 1}' | sort -nr | awk '{print "pushd" $ 2 "; svn cleanup; popd"}' | sh

¡No elimines tu solución!

en la carpeta .svn tiene un archivo llamado bloqueo, tiene 0 bytes de longitud

Puede eliminar todos estos archivos de todas las carpetas .svn en su solución y funcionará

Funcionó en mi caso

La descompresión en sitio de los archivos y un nuevo pago en la misma ubicación me han resuelto este problema.

En TortoiseSVN, para realizar una desversión en el lugar, arrastre hacia la derecha la carpeta raíz de la copia de trabajo de la lista de archivos en el árbol del directorio y elija "Exportar elementos versionados SVN aquí" en el menú emergente. TortoiseSVN se da cuenta de que el destino es el mismo que el de origen y sugiere deshacer la conversión de la copia de trabajo.

Después de la descompresión, realice un nuevo pago en la misma carpeta (que ahora contiene una copia no versionada de todos los archivos que tenía). TortoiseSVN le advertirá que está ingresando a una carpeta existente, pero puede continuar.

Después de esto, las limpiezas, actualizaciones y otras operaciones funcionaron sin problemas. Dado que los dos pasos anteriores preservan las modificaciones locales, no debería haber ninguna pérdida de información (pero respaldar la copia de trabajo antes de que esto sea una buena idea).

Una advertencia: si la copia de trabajo contiene versiones mixtas o cambios de propiedad no confirmados, esa información se perderá. Para mí, esto no es una ocurrencia común, y dada la elección de una copia de trabajo corrupta o la pérdida de cambios de propiedad no confirmados, tiendo a optar por la última.

Tuve este problema donde funcionaba la "limpieza", pero la "actualización" continuaría fallando. La solución que funcionó fue eliminar la carpeta en cuestión a través del Explorador de Windows, no la eliminación de TortoiseSVN (que marca la eliminación como algo para confirmar en el repositorio, y luego hice un "pago" para esencialmente "actualizar" la carpeta desde el repositorio.

Más información sobre la diferencia entre una eliminación de O / S y una eliminación de SVN aquí: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

Notablemente:

Cuando TortoiseSVN → Eliminar un archivo, se elimina de su copia de trabajo inmediatamente y se marca para su eliminación en el repositorio en la próxima confirmación.

Y:

Si un archivo se elimina a través del explorador en lugar de usar el menú contextual TortoiseSVN, el cuadro de diálogo de confirmación muestra esos archivos y le permite eliminarlos del control de versiones también antes de la confirmación. Sin embargo, si actualiza su copia de trabajo, Subversion detectará el archivo que falta y lo reemplazará con la última versión del repositorio.

Si estás en Linux, prueba esto:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Luego ejecute el cleanupcomando en ese directorio, luego intente actualizar.

Hice lo siguiente para solucionar mi problema:

1. Cambió el nombre de la carpeta ofensiva colocando una "_" delante del nombre de la carpeta.
2. Hizo una "limpieza" de la carpeta principal.
3. Cambió el nombre de la carpeta ofensiva a su nombre original.
4. Hizo un compromiso.

En el explorador de soluciones, haga clic con el botón derecho en el proyecto, en el submenú de apertura, haga clic en subversión y seleccione limpieza. Resolverá el problema, como lo hizo para mí. Espero que funcione.

Para hacer la limpieza

1. Elimine la carpeta .svn.

2. Haga el svncheckout en la carpeta raíz.

3. Intente realizar la operación de limpieza.

Esto resolvió mi problema.