SVN Obliterate!

Question

I was just thinking of writing a shell script to implement the obliteratee functionality in an easy to do way (externally, using the suggested way, but automated).

Here's what I had in mind:

On the client

1. svn list -R > file-list.
2. filter file-list in several ways like grep to create a file "files-to-delete", something like a set of grep XXX file-list>>files-to-delete.
3. transfer files-to-delete to the server using scp.

On the server

1. Dump the repository svnadmin dump /path/to/repos > repos-dumpfile, this can be kept as a backup too.
2. Filter the dump file, for each word in "files-to-delete", do: cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
3. Create a new repository and load the new file to it svnadmin create new-name; svnadmin load new-name < new-dumpfile

Would this work? How can it fail? Any other ideas?

Thanks.

Answer 1

So you're making a new repository any time you want to filter something out? Why not just delete the filtered files from the repository?

Answer 2

Yes, that script would work. But usually you don't obliterate that many files. Usually obliterate is only needed if you commit confidential information accidentally.

Are you sure you want to use obliterate for so many files?

Answer 3

I think cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile is a dangerous example. new-dumpfile will not be completely processed and it's contents will be probably lost, no?

From the comments below: the new-dumpfile will surely be lost, because the shell will clobber (truncate to zero length) it even before starting up the command.

Answer 4

What about files with the same path in different revisions? For example, if you commit /trunk/foo, then rename it to /trunk/bar, then commit something else at /trunk/foo that you want to obliterate. You don't want to lose the history of what's now /trunk/bar. Maybe svndumpfilter supports peg revisions?