tag - tortoise svn merge branch to trunk

Función de anulación de subversión

Question

Estaba pensando en escribir un script de shell para implementar la funcionalidad de borrado de una manera fácil de hacer (externamente, usando la forma sugerida, pero automatizada).

Esto es lo que tenía en mente:

En el cliente

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

En el servidor

1. Vuelque el repositorio svnadmin dump /path/to/repos > repos-dumpfile , esto también puede guardarse como una copia de seguridad.
2. Filtre el archivo de volcado, para cada palabra en "archivos para eliminar", haga: cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
3. Cree un nuevo repositorio y cargue el nuevo archivo svnadmin create new-name; svnadmin load new-name < new-dumpfile svnadmin create new-name; svnadmin load new-name < new-dumpfile

¿Esto funcionaría? ¿Cómo puede fallar? ¿Alguna otra idea?

Answer 1

¿Qué pasa con los archivos con el mismo camino en diferentes revisiones? Por ejemplo, si confirma /trunk/foo , cambie el nombre a /trunk/bar y luego escriba algo más en /trunk/foo que desee borrar. No desea perder el historial de lo que es ahora /trunk/bar . ¿Tal vez svndumpfilter admite revisiones de clavijas ?

Answer 2

Creo que el cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile 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 golpeará (truncará a longitud cero) incluso antes de iniciar el comando.

Answer 3

Sí, ese script funcionaría. Pero usualmente 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 quieres borrar para tantos archivos?

Answer 4

Tenía un requisito similar pero un poco más complejo. Varios cientos de revisiones en el pasado, algunos archivos de datos de muestra muy grandes (> 1 GB) fueron enviados 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, a la svn list se le puede dar un argumento de revisión. 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 mis 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