SVN: encuentra los files actualizados a la inexistencia

Estoy escribiendo un script de shell que puede almacenar el estado real de una copy de trabajo de SVN y restaurarlo más tarde, exactamente como estaba. Actualmente tengo un problema con una combinación rara y específica de revisiones de files y directorys que parece ser indetectable.

Digamos que hay un repository con dos revisiones. Hay dos casos:

  1. Supongamos que foo es un file (o un directory) que existe solo en la revisión 2. Al principio, toda la copy de trabajo está en la revisión 2. Luego, foo (y solo foo ) se actualiza a la revisión 1.

  2. Supongamos que la bar es un file (o un directory) que existe solo en la revisión 1. Al principio, toda la copy de trabajo está en la revisión 1. Luego, la bar (y solo la bar ) se actualiza a la revisión 2.

Ambos casos son muy similares, pero parece que tienen diferentes soluciones. En ambos casos, el file (o directory) simplemente desaparece. Sin embargo, la salida del svn status del command svn status no contiene información sobre eso.

¿Cómo crear mediante un script de shell una list de dichos files y directorys?


Hay una solución simple pero mala. Es posible usar el command svn list para get una list de files que deberían existir en la revisión actual y compararla con la list de files que realmente existen.

Esta solución es inaceptable porque lleva mucho time y genera un gran tráfico al server.


Publiqué la mejor respuesta que puedo encontrar. Aún así, funciona solo para el primer caso y tiene falsos positivos.

Una vez intenté hacer lo mismo que tú, y llegué a tantos casos de esquina que finalmente tomé una dirección completamente diferente. En lugar de usar un script, utilicé un repository git local.

Verifique una copy de trabajo del repository de Subversion, luego cree un repository de git local en esa carpeta usando git init . Agregue todo el contenido de su copy de trabajo de Subversion al repository git, incluidos los directorys de metadatos .svn , usando git add seguido de una git commit . Git ahora está haciendo un seguimiento de tu copy de trabajo más todos los metadatos de Subversion asociados a ella. Mi repository de git actual tiene 5 twigs diferentes, cada una basada en una revisión de Subversion diferente y que contiene diferentes sets de cambios que aún no han sido asignados al repository de Subversion. El repository de git hace que sea fácil cambiar de uno a otro, y Subversion funciona como si fueran copys de trabajo separadas. Incluso para copys grandes de trabajo, git hace un buen trabajo almacenando los contenidos de manera eficiente y cambiando de una twig a otra rápidamente.

Tenga en count que esto es diferente del command git svn , que es el método de git para interactuar directamente con un repository de Subversion. Encontré git svn para ser más complicado de usar y más fácil de romper cosas. Envolver una copy de trabajo normal de Subversion en un repository de git me permitió seguir haciendo todas mis operaciones de repository usando Subversion, y solo me requirió aprender algunos commands básicos de git ( add , commit , branch , checkout , etc.). Es un poco más fácil para alguien con experiencia en Subversion y nuevo en git; git svn está más orientado a alguien con experiencia en git y atascado en un repository de Subversion.

Encontré una solución parcial para el primer caso.

 svn status -u | grep '^........\*........ ' | cut -c 22- 

Este código muestra todos los files que existen en la revisión principal y no existen en el actual. Esto encuentra los files y directorys del primer caso. Sin embargo, genera falsos positivos cuando se elimina un file cuando el directory principal (que todavía existe) se actualiza para una revisión más baja.