We have a rather strict policy regarding our subversion repository that is also a large inconvenience. With our branches, anything that gets checked into subversion has to have redacted authentication credentials (e.g. database, user accounts, etc...). A file was added and committed with both names and passwords. There exists three revisions of this xml file:

First - File was added and committed with some irrelevant (to this question) content.
Second - File (among 3 other irrelevant files) was committed with authentication credentials as part of an entirely new block of XML.
Third - More files were added and checked in, none being newer versions of the bad file from the previous revision.
Fourth - Single bad file was checked in again with the authentication credentials (specifically, nothing else) removed.

I'd like to remove the second revision, and being that this is the first occurrence of this occurring, I've never had to deal with this before. I know it's difficult with subversion, as the intent of the software is to maintain your code revisions, not pick away and make changes to old revisions. Is this possible to delete one file from a previous revision, or overwrite it with the contents of a newer revision (i.e. replace the bad file from the second revision with the file from the fourth)?


There is currently no obliterate functionality in Subversion. It has been discussed on several occasions, but it messes with the integrity of the repository and has yet to be implemented.

WARNING: That link has 11 years worth of discussion on svn obliterate.

A work-around is to back up the repository using svnadmin dump (LINK) and then restore the repository using svndumpfilter (LINK) preventing specific revisions from being added to the restored repository.


You can do this with a bit of creative dump file editing. First of all you need to dump your repository out using

svnadmin dump repolocation > file.dump

You need to open up file.dump file in a text editor and find the revision the file was added. Look for Revision-number: xxx where xxx is the revision the second file was added. Below that you will find a block such as

Node-path: trunk/my/file1.txt
Node-kind: file
Node-action: change
Text-content-length: 14
Text-content-md5: c0bf20e1c2a520acddd3fccc2b9c5781
Text-content-sha1: 83162b1f0ca7b6e6816d2bc8f44550915fa2f4b7
Content-length: 14


If you remove the above block, the dump file should still work and it will be like the second file had never been added to the repository when you load the dump file into a new repository

However if you have to have the file showing (because potentially it contained some other modifications you need to do the following.

Where I am showing contentsinfile above, you will find the contents of the second file committed including the passwords. You should edit the passwords out but keep the length of the text the same! This is to keep the Content-length and Text-content-length to be correct! (You could also adjust the length but you are looking for more trouble) The problem now though is that the md5 and sha1 checksums you see above will not match. You will have to generate new md5 and sha1 based on the modified file content which may be pretty tricky but its not too hard!

Once you are done with the editing you need to load the modified dump file into a new repository

svnadmin create newrepo
svnadmin load newrepo < file.dump
  • Thank you, this really helped me! One problem I had is that my text-content-length didn't seem correct, this turned out to be because of unix <> windows file endings. – Pmarcoen Feb 20 '18 at 10:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.