Copia de trabajo XXX bloqueada y la limpieza falló en SVN

Para mí, el truco era ejecutar svn cleanup en 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.

Busque en su carpeta .svn, habrá un archivo en ella llamado lock. Borra ese archivo y podrás actualizarlo. Puede haber más archivos de bloqueo en el directorio .svn de cada subdirectorio. Tendrán que borrar 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 los archivos en la carpeta .svn. 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 local copia.

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

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

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

delete from WC_LOCK

Siguiendo el comentario de eakkas, es posible que también deba eliminar todas las entradas de la tabla WORK_QUEUE.

La manera más fácil:

1. Ir a Padre directorio(Carpeta) de Proyecto.
2. Pres Clic derecho
3. Presione en TortoiseSVNluego 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.

Compruebe las capturas de pantalla para su referencia.

Primer paso:

Segundo paso: Habilite la opción Break lock (segunda casilla de verificación en la ventana emergente de limpieza)

Espero que esto te ayude mucho.

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

Si este es su problema...:

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

De cualquier manera, es probable que necesite:

A) Renombrar el directorio existente a un nombre temporal

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

A partir de ahí, o bien

A) Copie los archivos relevantes en el directorio que se eliminó

B) Si ha tenido un cambio significativo de contenido en el directorio, haga un SVN delete en el original, confirme y cambie el nombre de su nuevo directorio al nombre deseado, seguido de un SVN add para obtener ese bajo control de versiones.

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

Este funcionó para mí.

1. Vaya a la carpeta raíz,
2. Clic derecho y limpieza
3. Compruebe todas las opciones disponibles
4. Presione ok

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

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

Otros programas también pueden mantener los archivos abiertos en el repositorio causando este problema. Excel sosteniendo un xls abierto fue un culpable en otra instancia, por lo que puede ser aconsejable cerrar todos los programas que pueden estar utilizando cualquier cosa en el repositorio o incluso reiniciar para forzar a los programas a cerrar y luego tratar de limpiar de nuevo.

Tuve este problema porque las carpetas externas no quieren estar vinculadas 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 SVN Woring Copy locked. 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 la propiedad svn: externals está listo. Esto creará la carpeta y todo estará bien de nuevo.

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

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

Me encontré exactamente con 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), encontré que hay un archivo db llamado "wc" en el .carpeta svn de su rama.

Abra el archivo db usando cualquier gestor de bases de datos (usé el plugin sqlite manager de Firefox) y vaya a la tabla WC_LOCK. Esta tabla tenga las entradas para los bloqueos adquiridos. Borra los registros de la tabla y listo:)

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

Si está en una máquina Windows, vea el repositorio a través de un navegador y puede ver dos archivos con el mismo nombre de archivo pero usando casos diferentes. Subversion es sensible a 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 lo hace. Elimine los nombres de archivos duplicados en el repositorio e inténtelo de nuevo.

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

Se arregló con un nuevo pago.

¿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 todo funky.

De lo contrario, para seguir adelante, exporte esa copia de trabajo a una nueva carpeta (no copie el .svn hidden folders), re-checkout el proyecto, y mover todo su código de nuevo, a continuación, proceder con su confirmación.

Simplemente borra el .svn, luego ejecute una limpieza en el directorio padre. Funciona perfectamente!!

En versiones bajo Mac OS: Acción - > Limpieza de la copia de trabajo se bloquea en...

A menudo tengo un problema así. Mi patrón que causa problemas de limpieza.

1. Abro el archivo de imagen en el visor.
2. Elimino el archivo/carpeta de imagen.
3. Estoy tratando de confirmar / actualizar

Cerrar el visor de imágenes donde se abre el archivo eliminado resuelve el problema. Tal vez otro software puede bloquear la limpieza de la misma manera.

En general. Creo que reiniciar el equipo 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 recuperen los archivos, esto se aclarará. Con frecuencia, el error se produce porque la" actualización " falló o se canceló prematuramente durante el progreso de la actualización.

1. Compruebe que los archivos se enumeran en .svn / prop-directorio base
2. Elimine cualquier archivo que no esté bajo la carpeta
3. Limpieza
4. Actualizar

Ahora la actualización debería funcionar.

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

No elimine su solución!

En el .svn folder tiene un archivo llamado lock es de 0 bytes

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

Funcionó en mi caso

El desversionamiento in situ de los archivos, y un nuevo checkout en la misma ubicación, ha resuelto este problema para mí.

En TortoiseSVN, para realizar un desversionado in situ, arrastre con el botón derecho la carpeta raíz de la copia de trabajo de la lista de archivos a sí misma en el árbol de directorios, y elija "SVN Export versioned items here" en el menú emergente. TortoiseSVN nota que el destino es el mismo que el origen, y sugiere desversionar la copia de trabajo.

Después de desversionar, haga una nuevo checkout en la misma carpeta (que ahora contiene una copia no versionada de todos los archivos que tenía). TortoiseSVN le avisará de que está ingresando a una carpeta existente, pero puede seguir adelante.

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

Una advertencia: Si la copia de trabajo contiene versiones mixtas o cambios de propiedad no comprometidos, 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 comprometidos, tiendo a optar por lo último.

Tuve este problema donde la "limpieza" funcionó, 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 "checkout" para esencialmente "actualizar" la carpeta desde el respository.

Más información sobre la diferencia entre un O / S delete y un SVN delete aqui: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

En particular:

Cuando TortoiseSVN → Eliminar un archivo, se elimina de su copia de trabajo inmediatamente, así como 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 de TortoiseSVN, el diálogo de confirmación muestra esos archivos y también le permite eliminarlos del control de versiones antes del compromiso. 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 comando cleanup en ese directorio, luego intente actualizar.

Hice lo siguiente para solucionar mi problema:

1. Cambió el nombre de la carpeta infractora colocando un " _ " delante de la nombre de la carpeta.
2. Hizo una "Limpieza" de la carpeta padre.
3. Cambió el nombre de la carpeta infractora a su nombre original.
4. Hizo un commit.

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

Para hacer la limpieza

1. Eliminar el .carpeta svn.

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

3. Intente realizar la operación de limpieza.

Esto solucionó mi problema.

Tenía esto bajo TortoiseSVN y el error estaba relacionado con un nuevo directorio que había creado bajo un nuevo proyecto. Acababa de crear este proyecto, así que no había forma de que este directorio hubiera existido antes. Miré en el navegador del repositorio y la nueva carpeta ya estaba en el repositorio, pero TortoiseSVN no la mostró como confirmada.

Para sortearlo, ya que acababa de crear la carpeta de todos modos, la borré en el repositorio y luego hice un commit. Funcionó fino.

Dado que hice esto fuera de Visual Studio, tuve que reiniciar Visual Studio para que lo resolviera todo de nuevo.

Iniciar la búsqueda....Bloqueo...Seleccione todos los archivos enumerados y eliminar..fijo