Cómo verificar la copy de trabajo de Subversion

Tengo una copy de trabajo de Subversion con al less un file perdido (se eliminó la copy local mientras se arreglaba un conflicto de tree). Es curioso porque el file está versionado, aparece en el repository, la resolución del conflicto del tree fue 100% local (sucedió en la actualización y no lo hice después) y he ejecutado "svn cleanup" varias veces, pero ninguna de Los clientes de Subversion (línea de command svn y TortoiseSVN) pueden detectar que la copy de trabajo está dañada. Ni siquiera revertir todos los cambios recuperó el file.

Lo arreglaré como siempre (nuevo pago en otro lugar y copy los cambios con WinMerge); De hecho, tengo una pregunta diferente:

¿Cómo se puede probar la validez de una copy de trabajo?

Por supuesto, siempre puedes verificar una nueva copy y usar una utilidad de comparación de files, pero … ¿no hay una forma mejor? ¿Hay alguna herramienta para verificar una copy de trabajo equivalente a svnadmin verify ?

=== ACTUALIZACIÓN ===

Tengo buenas respuestas con trucos para evitar la corrupción de copy de trabajo, pero mi pregunta era más en la línea de encontrar un método para estar 100% seguro de que la copy de trabajo es coherente y está vinculada con los contenidos reales del repository; en otros trabajos, un equivalente de copy de trabajo del command svnadmin verify .

Hasta ahora, parece que:

  • Subversion no proporciona esa herramienta y es posible que el formatting de datos SVN ni siquiera permita escribir uno.

  • La actualización de una revisión es una técnica que parece encontrar (y solucionar) algunos problemas, aunque a menudo es necesario retroceder a una revisión anterior y supongo que solo puede detectar files perdidos si se han modificado en el range de revisión.

  • Ver una nueva copy de trabajo parece el único método 100% confiable.

Esto parece un problema que experimenté hace un time: svn: el file en la copy de trabajo parece "perdido"

citando textualmente la respuesta de wcoenen:

Los clientes de SVN 1.6.1 (incluido TortoiseSVN) tenían un error por el cual las carpetas a veces se configuraban erróneamente como profundidad "vacía". Esto causa los síntomas que describes. (Tenga en count que es posible que la carpeta se haya convertido en "vacía" por svn 1.6.1 y se haya mantenido de esa manera, aunque ya se haya actualizado a un cliente svn más nuevo).

Para solucionarlo, use la opción de menu "actualizar a la revisión" en TortoiseSVN y select la profundidad "totalmente recursiva"

Si haces clic derecho en el file, bajo el menu SVN creo que hay un command llamado Diff. Esto se abrirá y resaltará las diferencias entre la versión local y la versión del repository, creo.

También puede ejecutar diff desde la línea de command si lo desea.

Tuve problemas similares cuando comencé a trabajar con SVN usando Tortoise en Windows. Cada vez que necesitaba copyr una carpeta, por ejemplo, al crear un nuevo complemento que estaba basado en otro ya existente, lo copyba y pegaba alegremente dentro de la copy de trabajo.

Lo que no sabía era que cuando hacía eso, copyba a lo largo del directory de metadatos .svn . Esto causa confusión interminable de subversión: si trabajas con un cliente gráfico, el nuevo directory parece estar correctamente registrado y el cliente te muestra una placa limpia después de cada confirmación. Pero, el nuevo directory nunca se registra .

Usted nota esto cuando revisa una nueva copy de trabajo en otro lugar, y luego está jodido porque esos files nunca estuvieron bajo control de versión. Me costó medio día reparar en ese momento.

Cuando necesite duplicar un directory en una copy de trabajo, siempre exporte primero, luego agréguelo.

Hasta ahora, tendré que suponer que no hay una manera confiable de hacerlo a less que realices una nueva confirmación y compares ambos treees de directorys. Si a un directory .snv le faltan datos pero no están realmente dañados, simplemente no hay suficiente información en la copy de trabajo para detectar que algunos files han desaparecido.

Si bien es posible que WC-NG cambie esto para mejor (o no), el formatting actual no es tan sólido como una roca.