Subversion Obliterate feature

Question

Estaba pensando en escribir un script de shell para implementar la funcionalidad de borrado de una manera fácil de hacer (externamente, usando el método sugerido, pero automatizado).

Esto es lo que tenía en mente:

En el cliente

1. svn list -R > file-list.
2. filtrar archivo-list de varias maneras como grep para crear un archivo "archivos-para-eliminar", algo así como un conjunto de grep XXX file-list>>files-to-delete.
3. transfiera files-to-delete al servidor usando scp.

En el servidor

1. Volcar el repositorio svnadmin dump /path/to/repos > repos-dumpfile, esto se puede guardar como una copia de seguridad también.
2. filtrado del archivo de volcado, para cada palabra en "archivos-to-delete", hacer: cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
3. Crear un nuevo repositorio y cargar el nuevo archivo para que svnadmin create new-name; svnadmin load new-name < new-dumpfile

Que este trabajo? ¿Cómo puede fallar? ¿Alguna otra idea?

Answer 1

Sí, ese script funcionaría. Pero generalmente no borra tantos archivos. Por lo general, el borrado solo es necesario si usted confía información confidencial accidentalmente.

¿Estás seguro de que deseas eliminar tantos archivos?

Answer 2

Creo que cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile es un ejemplo peligroso. new-dumpfile no se procesará completamente y sus contenidos probablemente se perderán, ¿no?

De los comentarios a continuación: el nuevo archivo de volcado seguramente se perderá, porque el caparazón tropezará (truncará a longitud cero) incluso antes de iniciar el comando.

Answer 3

¿Qué pasa con los archivos con el mismo camino en las diferentes revisiones? Por ejemplo, si confirma /trunk/foo, cámbiele el nombre a /trunk/bar, luego, ejecute otra cosa al /trunk/foo que desea borrar. No desea perder el historial de lo que ahora es /trunk/bar. ¿Tal vez svndumpfilter es compatible con peg revisions?

Answer 4

Tenía un requisito similar pero un poco más complejo. Varios cientos de revisiones en el pasado, algunos muy archivos de datos de muestra de gran tamaño (> 1 GB) se enviaron al repositorio. Luego fueron movidos y finalmente eliminados de HEAD. Sin embargo, todavía estaban en la historia de revisión, lo que hace que el repositorio sea excesivamente grande. No pude usar svn list -R, ya que los archivos ya no aparecen en la copia de trabajo.

Sin embargo, se puede dar un argumento de revisión a svn list. No estaba seguro exactamente cuándo se habían registrado los archivos grandes, pero sabía que era en algún momento después de la revisión 2000. También tenía una lista de nombres de archivos.Así que utilicé un bucle simple y uniq para generar mi files-to-delete:

cd $working_copy 
for rev in {2000..2437}; do 
    svn ls -R -r$rev | grep -f ~/tmp/big-file-names >> ~/tmp/file-paths; 
done 
cat ~/tmp/file-paths | sort | uniq > ~/tmp/files-to-delete 
cd ~/tmp 
# You should inspect "files-to-delete" to see if it looks reasonable! 
cat dumpfile | svndumpfilter exclude `cat files-to-delete` > dumpfile.new