2011-01-04 16 views
16

Esto me ha estado atormentando durante una semana.SVN Endless Loop - [archivo] "no existe en el repositorio"

SVN me sigue diciendo que un determinado archivo "does not exist in repository".

Bien. Vamos a eliminarlo. Olvídalo. Ignoralo. Lo que sea. Realmente no me importa este archivo (especialmente si continúa fallando el check-in nocturno).

¿La parte más extraña? Una "restauración" en realidad RESTAURARÁ el archivo del repositorio, por lo que está allí (¿está dañado, tal vez?).

... y esto tiene que ser la guinda del pastel. Si elimino el archivo a través del Explorador de Windows, SVN RESTABLECERÁ el archivo desde el repositorio, y justo después de ese estado, que no existe en el repositorio. WTF?

¿Alguien tiene una idea de cómo deshacerse de esto?

Ya he intentado limpiezas, reversiones, eliminaciones y cualquier otra cosa imaginable, pero esta me tiene perplejo.

Gracias por cualquier consejo que pueda tener ...

+0

¿trató de 'renombrar SVN 'ese archivo (para eliminar el '^')? Y luego confirmar, luego eliminar (y volver a enviar) – VonC

Respuesta

17

Parece más probable es que usted ha corrompido su copia de trabajo local, por ejemplo, moviendo carpetas o alguna otra manipulación que hiciste con el explorador de Windows, pero debería haberlo hecho a través del menú contextual de TortoiseSVN. La información dentro de las carpetas .svn ahora ya no coincide con el estado de la copia de trabajo, lo que confunde a Subversion.

Para solucionar esto, elimine la carpeta principal ("Originales") en su copia de trabajo con el explorador de Windows (NO con TortoiseSVN). Luego haga una "actualización" de TortoiseSVN en la raíz de su copia de trabajo. Esto debería restaurar la carpeta en funcionamiento.

Otra opción es descartar por completo su copia de trabajo y hacer una nueva comprobación.

Tenga en cuenta que la próxima versión de Subversion (1.7) reducirá las oportunidades de corromper su copia de trabajo al centralizar todos los metadatos en una sola carpeta .svn en la raíz.

+1

Puedo confirmar que esta es una situación común. La copia de trabajo puede corromperse (pero permanecer coherente) y no hay forma de averiguarlo. El pago final es la única solución confiable. –

+0

Hola Wim: tu primera sugerencia fue el truco. ¡Gracias! Ah, y buenas noticias sobre 1.7 tratando de minimizar algo de esto. SVN 1.6 es un poco implacable con errores menores. – Flipster

+0

Esperando que haya otra manera ... Eliminar la carpeta adjunta no es una opción para mí :( – jowie

0

He tenido problemas similares con las copias de trabajo dañadas. En ocasiones, las copias de trabajo tienen muchos cambios pendientes pero no pueden registrarse. Para resolver esto, yo utilizo el siguiente enfoque (SVN 1.7+):

  1. una copia de trabajo fresca en un nuevo directorio (via2)
  2. En la copia de trabajo nueva, si el archivo infractor está ahí, eliminar si es necesario
  3. Commit copiar el trabajo fresca
  4. En la copia de trabajo nueva, elimine todo excepto el directorio .svn
  5. Copia de todo, desde la vieja copia de trabajo, salvo que el directorio .svn en la copia de trabajo nueva.
  6. comprometer a la copia de trabajo nueva nuevo
  7. Borrado (o de reserva) la vieja copia de trabajo
  8. Cambie el nombre del trabajo nueva a la vieja copia de trabajo (via2 de ruta)
Cuestiones relacionadas