Subversion caratteristica Obliterate

Question

Stavo pensando di scrivere uno script di shell per implementare la funzionalità obliterate in un modo semplice per farlo (dall'esterno, utilizzando il modo suggerito, ma automatizzato).

Ecco quello che avevo in mente:

Sul client

1. svn list -R > file-list.
2. file-lista dei filtri in diversi modi, come grep per creare un file "file-to-delete", qualcosa di simile a una serie di grep XXX file-list>>files-to-delete.
3. trasferimento files-to-delete al server utilizzando SCP.

Sul server

1. Dump il svnadmin dump /path/to/repos > repos-dumpfile repository, questo può essere tenuto come un backup troppo.
2. Filtrare il file di dettagli, per ogni parola in "files-to-delete", fanno: cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
3. Crea un nuovo repository e caricare il nuovo file ad esso svnadmin create new-name; svnadmin load new-name < new-dumpfile

Sarebbe questo lavoro? Come può fallire? Tutte le altre idee?

Answer 1

Sì, lo script avrebbe funzionato. Ma di solito non cancellare che molti file. Di solito Obliterate è necessaria solo se si impegnano informazioni riservate accidentalmente.

Sei sicuro che si desidera utilizzare per cancellare così tanti file?

Answer 2

Credo cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile è un esempio pericoloso. new-dumpfile non sarà completamente elaborato e il suo contenuto sarà probabilmente persa, no?

Da commenti qui sotto:. Il nuovo-dumpfile sarà sicuramente perduto, perché la shell clobber (troncare alla lunghezza zero) ancor prima di avviare il comando

Answer 3

Ho avuto un requisito simile, ma leggermente più complesso. Diverse centinaia di revisioni in passato, un po 'di molto di grandi dimensioni (> 1GB) file di dati di esempio sono stati impegnati per il repository. Sono stati poi spostati e alla fine eliminati dal TESTA. Tuttavia erano ancora nella storia di revisione, rendendo il repository modo inefficiente di grandi dimensioni. Non ho potuto usare svn list -R, dal momento che i file sono apparsi non è più nella copia di lavoro.

Tuttavia, svn list può essere dato un argomento di revisione. Non ero sicuro esattamente quando i file di grandi dimensioni erano stati controllati, ma sapevo che era qualche tempo dopo la revisione 2000. Ho avuto anche un elenco di nomi di file. Così ho usato un semplice loop e uniq per generare la mia 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

Answer 4

Che dire di file con lo stesso percorso in diverse revisioni? Ad esempio, se si impegnano /trunk/foo, poi rinominarlo in /trunk/bar, poi commettere qualche altra cosa in /trunk/foo che si desidera cancellare. Non si vuole perdere la storia di ciò che è ora /trunk/bar. Forse svndumpfilter supporta peg revisioni ?