Carpetas obstruidas en Subversion

¿Qué diablos significa "obstruido" cuando intentas registrarte en Subversion? Veo dos carpetas en rojo con el texto de estado de "obstruido". No veo lo que esto significa en ninguna parte de los documentos.

Cuando pruebo el cleanupcomando, aparece "el nombre de la carpeta no es un directorio de trabajo". Esta es una carpeta que acabo de crear en VS, y cuando trato de agregarla a Subversion me da ese error. Todas las demás carpetas están bien.

ocurre cuando ha eliminado o movido los subdirectorios .svn (sin pasar por los comandos SVN), por lo que SVN tiene una vista corrupta de la copia de trabajo.

Primero intente una limpieza, y si eso no lo resuelve, revierta (o actualice) el directorio para restaurar las carpetas del subdirectorio .svn.

Sin saber qué causa esto, la solución puede ser exportar la copia de trabajo (el pago completo que tiene localmente) a otro lugar.

Si está utilizando tortoisesvn, tiene la opción de "exportar archivos no versionados", pero creo que si lo hace desde la línea de comandos solo exporta archivos versionados, por lo que podría ser una tarea laboriosa copiar archivos no versionados manualmente .

Una vez hecho esto, revise una copia de trabajo limpia y luego suelte la copia de seguridad exportada que tiene sobre ella. Es muy importante que la copia de seguridad no tenga carpetas .svn.

He visto estos errores antes cuando las personas han extraído copias de trabajo dentro de otras copias de trabajo o cualquier otra cosa que dañe las entradas .svn.

Tuve el mismo problema y lo arregló así:

• renombrado el directorio obstruido
• creó el directorio con su nombre original en SVN (por ejemplo, svn mkdir)
• actualicé la carpeta principal, por lo que el directorio recién creado aparece en mi copia de trabajo
• Copié los archivos del directorio obstruido al directorio recién creado y los confirmó

Si está en un sistema * nix, asegúrese de no haber creado un archivo, agréguelo a SVN, luego bórrelo y reemplácelo con una carpeta del mismo nombre. No ayuda a OP, pero con suerte le ahorrará mucho estrés a alguien.

Esto significa que, por alguna razón, se ha producido un conflicto durante la operación. Verifique si hay un archivo o carpeta sin versión existente con el mismo nombre que uno con versión.

(Parafraseado del archivo de ayuda del cliente Tortoise SVN)

Nada funcionó para mí, así que hice lo siguiente:

• exportado con los archivos no versionados en una nueva ubicación
• renombrado la carpeta existente
• movió la carpeta desde la ubicación de exportación en el proyecto
• renombrado la nueva carpeta
• agregar, comprometer
• eliminó la carpeta antigua y renombrada
• renombrado la nueva carpeta
• cometer

Hay diferentes variaciones de escenario que pueden causar esta situación. Aquí hay un ejemplo:

Terminé con el! marque en un directorio que cambió de nombre de www a www_a sin usar el comando 'svn rename':

1. Cambie el nombre del directorio actual que lleva el nombre original, por ejemplo a www_b
2. Cambiar el nombre de www_a de nuevo a www
3. Asegúrese de hacer 'svn update' o 'svn revert' dentro del directorio www
4. Elimine el directorio www actualizado sin usar 'svn delete'
5. Vaya al directorio principal y emita 'svn update'
6. Esto restaurará el directorio www original.
7. Esta vez use 'svn rename' para renombrar www a www_a
8. Cambiar el nombre de www_b a www
9. Use 'svn add' para agregarlo al repositorio

Debería obtener un directorio de trabajo svn correcto en este punto. Y aprenda una o dos cosas sobre cómo resolver la confusión del directorio svn.

Enfrenté este problema en una máquina con Windows.

Había revisado el directorio antes de revisar todo el proyecto al que pertenecía. Causó el problema 'obstruido' para mí.

Simplemente eliminé esa carpeta y ejecuté una actualización desde la raíz (de esa carpeta). Funcionó bien.

Los comandos como limpieza, etc. no me funcionaron.

Algunas palabras de precaución:

1. Esto es costoso si la carpeta es grande.
2. Hará que pierda todos sus cambios si hay alguno.

Todo lo mejor.

También he visto esto en Windows cuando he creado un enlace simbólico a un directorio de repositorio; en este caso, la raíz del repositorio se ve como "obstruida". Sin embargo, esto no parece tener ningún efecto.

Pasos para reproducir:

1. Mira tu repositorio

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Verifique que su directorio esté bien

   cd plugin_dir
   svn st -u
   

   La salida debe ser

   Status against revision: 1234
   

3. Cree el enlace simbólico (que muestra el problema)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   La salida será

   ~           1234  .
   Status against revision: 1234
   

Me encontré con este problema al pegar una carpeta con subdirectorios en mi copia de trabajo usando mi cliente FTP: sabía que me equivoqué tan pronto como presioné el botón de transferencia ... los peligros de trabajar demasiado tarde.

Intenté todas las sugerencias anteriores y otras encontradas en línea en vano. Cada opción produjo el error de que mi directorio estaba bloqueado y la operación no se pudo realizar.

Entré en mi copia de Time Machine, restauré el directorio y estaba listo. Limpié la copia de trabajo como precaución, actualicé mis archivos correctamente y volví a trabajar.

A menudo tenemos varias ramas en el camino al mismo tiempo, para ahorrarme cambiar o perder el tiempo con la configuración de IIS, verifico cada rama en una carpeta separada. Luego uso el enlace de directorio para conectar esas carpetas de nuevo a la ruta principal configurada en IIS.

Entonces, para mí, el directorio vinculado siempre tiene una exclamación amarilla y está marcado como obstruido. Creo que esto se debe a que técnicamente fue creado / movido fuera de SVN.

Obtengo este estado de "obstrucción" en los directorios cuando realizo actualizaciones a un CMS (WordPress o Drupal) a través de la interfaz web: la aplicación no es consciente de que su código es en realidad una copia de trabajo de subversión, por lo que al actualizar un complemento, elimina ese complemento directorio (incluido el .svndirectorio) y cae en un nuevo directorio desde la nueva versión del complemento.

Para recuperar ese .svndirectorio, desde el directorio que contiene el directorio obstruido. Hago un pago con --force. Por ejemplo, si plugin_direstá marcado "~", desde su directorio padre ejecuto:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Cualquier archivo que ya esté solo se deja marcado y "E" en la salida del comando de pago (marcado como "M" cuando ejecuto svn status).

A veces tengo que regresar y agregar cualquier archivo que fuera nuevo con la actualización; o eliminar archivos que deberían eliminarse como parte de la actualización, ya que reaparecieron cuando hice el pago. Creo que estos están marcados como "A" en el pago, pero un posterior svn statusno los mencionará.

Me encontré con esto en Eclipse, donde algunos archivos estaban marcados con un signo de exclamación rojo. El problema era una carpeta .svn perdida en el directorio de origen. Eliminé la carpeta .svn, actualicé eclipse y pude registrar los archivos.

Esto también puede suceder cuando actualiza su subversión a una versión que XCode no admite.

Aquí está la forma más simple (y más segura) que he encontrado para resolver esto:

1. Cambie temporalmente el nombre del archivo o directorio ofensivo (o un directorio padre) que esté obstruido (por ejemplo, agregue ".backup").
2. Elimine cualquier .svndirectorio dentro del directorio renombrado (si corresponde).
3. svn revert el objeto renombrado (y ahora perdido) del paso 1.
4. svn delete El objeto revertido.
5. Cambie el nombre de la copia de seguridad del paso 1 a su nombre original.
6. Agregue y registre el objeto renombrado nuevamente en svn como un nuevo objeto.

Esto se me ocurrió cuando reemplacé un archivo con una carpeta, que tenía exactamente el mismo nombre. Se resuelve eliminando el archivo anterior, confirme y luego agregue el nuevo. Un poco hacky, pero funcionó para mí :)

Eliminé .svn en directorios obstruidos y lo actualicé desde afuera. Luego, el comando svn externo reconocerá estos archivos.