español - tortoisesvn mac
Copia de trabajo XXX bloqueada y error de limpieza en SVN (30)
¡No borres tu solución!
en la carpeta .svn tiene un archivo llamado lock que tiene 0 bytes de longitud
Puede eliminar todos estos archivos de todas las carpetas .svn en su solución y funcionará
Funciono en mi caso
Recibo este error cuando hago una svn update :
Copia de trabajo XXXXXXXX bloqueado Ejecute el comando "Limpiar"
Cuando corro la limpieza, me sale
La limpieza no pudo procesar las siguientes rutas: XXXXXXXX
¿Cómo salgo de este bucle?
¿Está utilizando TortoiseSVN y acaba de actualizar? He tenido ese problema antes al pasar de 1.4 a 1.5 y no reiniciar. (Intente un reinicio).
La razón por la que necesita reiniciar es porque el archivo de caché se vuelve todo funky.
De lo contrario, para continuar, exporte esa copia de trabajo a una nueva carpeta (no copie las carpetas ocultas .svn), vuelva a verificar el proyecto, y devuelva todo su código, luego continúe con su confirmación.
A menudo me sale un problema así. Mi patrón que causa problemas de limpieza.
- Abro el archivo de imagen en el visor.
- Borro el archivo de imagen / carpeta.
- Estoy tratando de cometer / actualizar
Cerrar el visor de imágenes donde se abre el archivo eliminado resuelve el problema. Tal vez otro software pueda bloquear la limpieza de la misma manera.
En general. Creo que reiniciar la computadora puede ayudar en tales casos.
Busque en su carpeta .svn , habrá un archivo llamado lock . Borre ese archivo y podrá actualizar. Puede haber más archivos de bloqueo en el directorio .svn de cada subdirectorio. Necesitarán eliminar también. Esto se podría hacer como un lote de forma sencilla 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 copia local.
Cuando tengo este problema, encuentro que ejecutar el comando de limpieza directamente en la ruta del problema generalmente parece funcionar. Luego volveré a ejecutar la limpieza desde la raíz de trabajo y se quejará de algún otro directorio. Y solo lo repito hasta que deje de quejarse.
En el explorador de soluciones, haga clic derecho en el proyecto, en el submenú de apertura, haga clic en subversión y seleccione la limpieza. Resolverá el problema, como lo hizo para mí. Espero que funcione.
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
Siguiendo el comentario de eakkas , es posible que también deba eliminar todas las entradas de la tabla WORK_QUEUE .
En versiones bajo Mac OS: Acción -> Limpiar los bloqueos de copia de trabajo en ...
Encontré exactamente el mismo problema usando SVN 1.7 y ninguna de las soluciones mencionadas anteriormente funcionó.
Ante todo, asegúrese de realizar una copia de seguridad de todo el 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 de base de datos llamado "wc" en la carpeta .svn de tu rama.
Abra el archivo db con cualquier administrador de db (usé el plugin sqlite manager de firefox) y navegue a la tabla WC_LOCK. Esta tabla tendrá las entradas para los bloqueos adquiridos. Eliminar los registros de la tabla y listo :)
Este funcionó para mí.
- Ve a la carpeta raíz,
- Clic derecho y limpieza
- Compruebe todas las opciones disponibles
- Presiona OK
Después de la limpieza, le permitirá actualizar a la última versión.
Hice lo siguiente para solucionar mi problema:
- Cambió el nombre de la carpeta ofensiva colocando una "_" delante del nombre de la carpeta.
- Hizo una "limpieza" de la carpeta principal.
- Cambió el nombre de la carpeta ofensiva a su nombre original.
- Hizo un commit.
Iniciar búsqueda .... Bloquear ... Seleccionar todos los archivos de la lista y eliminarlos ... corregidos
La desinstalación in situ de los archivos y un nuevo proceso de pago en la misma ubicación me han solucionado este problema.
En TortoiseSVN, para realizar una desinstalación in situ, arrastre hacia la derecha la carpeta raíz de la copia de trabajo desde la lista de archivos a sí misma en el árbol de directorios, y elija "Exportar elementos SVN versionados aquí" en el menú emergente. TortoiseSVN advierte que el destino es el mismo que el origen y sugiere que se elimine la versión de trabajo.
Después de la desinstalación, realice una nueva comprobación en la misma carpeta (que ahora contiene una copia no versionada de todos los archivos que tenía). TortoiseSVN le avisará que está registrando 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 que esto, sin embargo, puede ser 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 perder cambios de propiedad no comprometidos, tiendo a optar por esta última.
La forma más fácil de todas:
- Ir al directorio principal (carpeta) del proyecto .
- Presion clic derecho
- Presione en TortoiseSVN luego presione Limpiar ...
- El diálogo de limpieza aparecerá automáticamente
- Seleccione
Clean up working copy status,Break locks,Fix time stamps,Vacuum pristine copies,Refresh shell overlays,Include externals - Pres ok
Hiciste tu trabajo exitosamente.
Compruebe las capturas de pantalla para su referencia.
Primer paso:
Segundo paso: habilitar la opción de bloqueo de ruptura (segunda casilla de verificación en la ventana emergente de limpieza)
Espero que esto te ayude mucho.
La forma más sencilla de hacerlo es mostrar las carpetas ocultas y luego abrir la carpeta .SVN. Debería ver un archivo de cero KB denominado "bloqueo", lo que solucionará el problema
Lo hice simplemente creando una nueva carpeta, revisando el proyecto, copiando los archivos actualizados a la nueva carpeta.
Fue arreglado con un nuevo checkout.
Para hacer la limpieza
Eliminar la carpeta .svn.
Haga el svncheckout en la carpeta raíz.
Intente realizar la operación de limpieza.
Esto resolvió mi problema.
Para mí, el truco fue 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.
Para mí, en realidad fue culpa de Tortuga, algo así. Tortoise se quejó "no se puede limpiar, ejecutar la limpieza", pero cuando ejecuté la línea de comandos (svn cleanup), claramente me dijo que no podía eliminar algunos archivos que estaban en uso, cuya solución era obvia. Una vez que cerré Visual Studio (que mantenía los archivos abiertos), la limpieza funcionó bien.
Otros programas también pueden mantener archivos abiertos en el repositorio que causa este problema. Excel mantener un xls abierto fue el culpable en otra instancia, por lo que puede ser conveniente cerrar todos los programas que puedan estar usando algo en el repositorio o incluso reiniciar para forzar que los programas se cierren y luego intenten la limpieza nuevamente.
SVN normalmente actualiza su estructura interna (.svn / prop-base) de los archivos en una carpeta antes de que los archivos reales sean recuperados 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.
- Compruebe que los archivos se enumeran en el directorio .svn / prop-base
- Eliminar cualquier archivo que no esté en la carpeta
- Limpiar
- Actualizar
Ahora la actualización debería funcionar.
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 de cleanup en ese directorio, luego intente actualizar.
Si se encuentra en una máquina con Windows, vea el repositorio a través de un navegador y puede que vea dos archivos con el mismo nombre de archivo pero utilizando diferentes casos. Subversion distingue entre mayúsculas y minúsculas y Windows no, por lo que puede obtener un bloqueo cuando Windows cree que está tirando el mismo archivo y Subversion no. Elimine los nombres de archivos duplicados en el repositorio e intente nuevamente.
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, por lo que no había forma de que este directorio existiera antes. Busqué en el navegador del repositorio y la nueva carpeta ya estaba en el repositorio, pero TortoiseSVN no lo mostró como comprometido.
Para evitarlo, ya que acababa de crear la carpeta de todos modos, la eliminé en el repositorio y luego hice una confirmación. Funcionó bien
Ya que hice esto fuera de Visual Studio, tuve que reiniciar Visual Studio para que se diera cuenta de todo nuevamente.
Tuve este problema donde funcionaba la "limpieza", pero la "actualización" seguirí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 (lo que marca la eliminación como algo para comprometerse con 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 O / S y una eliminación 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 se elimina un archivo a través del explorador en lugar de usar el menú contextual de 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 faltante y lo reemplazará con la última versión del repositorio.
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 de SVN Woring Copy bloqueado. 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 de nuevo.
Este problema surgió para mí porque svn: externals for files requiere que la carpeta de destino sea controlada por versión. Después de que noté que esto no funciona en diferentes repositorios, cambié de archivos externos a carpetas externas y me metí en este lío.
Tuvo el mismo problema porque exporté una carpeta bajo una carpeta controlada por 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?)
Un colega en el trabajo ve constantemente este mensaje, y para él es porque eliminó un directorio bajo el control de versiones de SVN sin borrarlo de SVN, y luego creó un nuevo directorio en su lugar, no bajo el control de versiones, con el mismo nombre.
Si este es tu problema ...:
Hay diferentes maneras de solucionarlo, dependiendo de cómo / por qué se reemplazó el directorio.
De cualquier manera, es probable que necesites:
A) Renombrar el directorio existente a un nombre temporal
B) Haga un reenvío SVN para recuperar el directorio eliminado del sistema de archivos, pero no de SVN
A partir de ahí, usted tampoco
A) Copie los archivos relevantes en el directorio que fue eliminado
B) Si tuvo un cambio significativo en el contenido del directorio, realice una eliminación de SVN en el original, confirme y cambie el nombre de su nuevo directorio al nombre deseado, seguido de un agregado de SVN para obtener ese bajo control de versiones.
Un enfoque sería:
- Copie los elementos editados a otra ubicación.
- Eliminar la carpeta que contiene la ruta del problema.
- Actualice la carpeta que contiene a través de Subversion.
- Copie sus archivos de nuevo o fusione los cambios según sea necesario.
- Cometer
Otra opción sería eliminar la carpeta de nivel superior y revisar nuevamente. Esperemos que no llegue a eso sin embargo.
simplemente elimine las carpetas .svn, luego ejecute una limpieza en el directorio principal. ¡¡Funciona perfectamente!!