Error de SVN: no es una copia de trabajo

Recientemente nuestro servidor svn fue cambiado e hicimos un cambio svn.

Como la copia de trabajo tenía una gran cantidad de recursos no versionados, la copia de trabajo se bloqueó y comenzamos a cambiar carpeta por carpeta para todas las carpetas en svn, lo que funciona perfectamente bien.

Pero en el nivel más alto del repositorio, cuando intento actualizar archivos, obtengo el svn: Working copy '.' error bloqueado y limpieza tampoco ayuda. Cuando hago la limpieza, recibo errores como estos: svn: 'contenido' no es un directorio de copia de trabajo

El nuevo pago NO es una opción en absoluto. ¿Hay alguna otra forma de limpiar y liberar los bloqueos y hacer el cambio por completo?

EDITAR: El último párrafo en la respuesta de JesperE

Si obtiene una "copia no funcional" cuando realiza una "limpieza svn recursiva", supongo que tiene un directorio que debería ser una copia funcional (es decir, el directorio .svn en el nivel superior lo dice), pero le falta su propio directorio .svn. En ese caso, podría intentar simplemente eliminar / mover ese directorio y luego hacer una actualización local

Parece ser la solución al problema en el repositorio. ¡Identifiqué esas carpetas e hice un nuevo pago de esas carpetas específicas solo y wow, los bloqueos se liberan en la limpieza posterior! Muchas gracias JesperE !!

Pero, todavía no puedo entender el error del interruptor svn que ahora dice algo como,

svn: El repositorio en 'svn: // repourl / reponame / foldername' tiene uuid 'm / reponame', pero el WC tiene 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Algunas ideas ?

Si obtiene un "no una copia de trabajo" al hacer un recursivo, svn cleanupsupongo que tiene un directorio que debería ser una copia de trabajo (es decir, el .svndirectorio en el nivel superior lo dice), pero le falta su propio .svndirectorio. En ese caso, podría intentar eliminar / mover ese directorio y luego hacer una actualización local (es decir rm -rf content; svn checkout content).

Si obtiene un not a working copyerror, significa que Subversion no puede encontrar un .svndirectorio adecuado allí. Verifique si hay un .svndirectorio encontents

La solución ideal es un nuevo pago, si es posible.

Me metí en una situación similar ( svn: 'papers' is not a working copy directory) de una manera diferente, así que pensé en publicar mi historia de batalla (simplificada):

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

¡Uy! corregir permisos ... entonces:

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

E incluso moverse papersfuera del camino y correr svn up(que funcionó para el OP) no lo solucionó. Esto es lo que hice:

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

Eso funciono.

Lo resolví por

1. Copie una copia de seguridad de las carpetas afectadas
2. SVN revierte las carpetas afectadas
3. Pegue los archivos desde la copia de seguridad

En mi caso, el problema se debió a la eliminación de archivos .svn.

Tal vez acabas de copiar el árbol de la carpeta e intentas agregar el más bajo.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

en ese caso, debe comprometer el directorio en el nivel superior.

Solución alternativa: cambie el nombre del directorio que no sea 'copia de trabajo'. Pague / actualice / restaure este directorio nuevamente Mueva los archivos del directorio renombrado a los nuevos Confirmar cambios

Motivo: realizó algunos cambios en algunos archivos del directorio .svn, esto rompe la 'copia de trabajo'

Si creó un archivo dentro de un nuevo directorio, en lugar de 'svn add newdir / newfile' use 'svn add newdir' porque necesita agregar el directorio. Todos los archivos dentro del directorio se agregarán por defecto.

Acabo de recibir "no una copia de trabajo", y para mí la razón fue el Automouter en Unix. Solo un nuevo "cd / path / to / work / directory" hizo el truco.

Igual, necesitaba actualizar una carpeta 'contrib':

1. Movió la carpeta vieja,
2. Copié el nuevo
3. Copié las carpetas .svn en cada carpeta nueva (solo tres en mi caso).

En mi caso también, el problema se debió a las carpetas .svn eliminadas.

Resuelto

Intenté pegar la carpeta .svn de la subcarpeta a la carpeta raíz. ¡¡¡Funciona!!!

Esto es lo que hice:

1. renombrar tronco a tronco_
2. crear un nuevo tronco de carpeta
3. Vuelva a pagar e interrumpa el proceso después de que se hayan retirado algunos archivos
4. Mueve los archivos de trunk_ a trunk
5. Hacer svn limpieza
6. Hacer svn update. Esto actualizará el estado de los archivos y luego todos sus archivos serán versionados.

También encuentro este problema en la operación svn diff, fue causado por una ruta de archivo incorrecta, debe agregar './'para indicar el directorio de archivos actual.

svn: El repositorio en 'svn: // repourl / reponame / foldername' tiene uuid 'm / reponame', pero el WC tiene 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Cada repositorio de subversión tiene un identificador único (uuid). Subversion usa esto para asegurarse de que el repositorio sea realmente el mismo cuando se hacen cosas como cambiar. Probablemente debería cambiar el uuid en el servidor para que sea el mismo que antes.

¿Podría ser un formato de copia de trabajo que no coincide? Cambió entre svn 1.4 y 1.5 y las herramientas más nuevas convierten automáticamente el formato, pero las más antiguas ya no funcionan con la copia convertida.

Debe haber eliminado un archivo SVN - base de su proyecto (que son archivos de solo lectura). Debido a esto, obtienes este error.

Vuelva a revisar un proyecto nuevo, combine los cambios (si los hubiera) de su proyecto SVN anterior con uno nuevo usando "Winmerge" y confirme los cambios en su último pago.

@JesperE menciona que necesitas cambiar el uuid. Lo siguiente debería ayudarlo a lograr esto.

En SVN 1.5+, puede hacer svnadmin setuuid; luego puede verificar que se haya configurado correctamente usando svnlook uuid. En versiones anteriores de SVN, es un proceso más difícil. Ver http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

Además, el UUID de "m / reponame" parece sospechoso. Creo que debería ser un número con formato hexadecimal como el de la copia de trabajo, por lo que tal vez esta acción mejore las cosas en general :-)

[Originalmente comenté la respuesta de @ JesperE , pero creé esta respuesta para que sea más obvia para las personas y más útil para Google. Desde entonces he eliminado mis comentarios. ]

Tuvo el mismo problema, resultó que teníamos Slik 1.6.2 y Tortoise en la misma máquina. Tortoise había sido actualizado (y había actualizado la copia de trabajo) pero Slik no, así que Tortoise funcionó bien, pero las líneas de comando fallaron con:

svn: '.' no es un directorio de copia de trabajo

La eliminación de Tortoise y Slik, luego la reinstalación de Tortoise con las herramientas de línea de comando habilitadas me arregló esto.

para mac: - realice el pago desde el lado del servidor y se abrirá una nueva ventana para seleccionar el directorio de su máquina local, luego coloque todo el código en la carpeta seleccionada, luego abra svn local y agregue y confirme el proyecto

Hoy he encontrado el mismo problema /FILE_NAME/ is not a working copyen la mañana y he pasado más de dos horas para resolverlo. Después de mucho tiempo de RND y Google encontré alguna solución y esa es CHECKOUT.

1. CHECKOUTdel SUBVERSIONlocal como nuevo proyecto.
2. Cambie parte del código en el archivo java y COMPROMETE el proyecto.
3. Funciona para mi.

Espero que te sea útil.

Recientemente estaba usando otros desarrolladores Mac. Tuve la misma situación, el problema era; primero necesitaba escribir get repo path to terminal pero no lo hice, entonces dice cuál es su nombre de usuario y contraseña.

Acabo de encontrar un caso en el que el directorio .svn está en un servidor nfs en una máquina diferente, y el cliente nfs no estaba ejecutando el servicio de bloqueo de archivos ( lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

Esto desapareció una vez que lockdse inició en el host del cliente nfs.

Parece que la subversión podría aparecer con un mejor mensaje de error cuando tiene problemas para bloquear archivos. Esta fue la subversión 1.10.0

Hice un nuevo pago desde el mismo proyecto a una ubicación diferente, luego copié la carpeta .svn y lo reemplacé con mi carpeta .svn anterior. Después de eso llamó a la función de actualización svn y todo se sincronizó correctamente al día.

Elimine la carpeta .svn que está presente en su máquina local. Presione el ícono de Windows y escriba .svn, elimine toda la carpeta. Funcionó para mi.