In Subversion what are best practices to modifying historical files?

Question

Lets say I have the files

helloworld.c
helloworld.m

Fifteen edits ago someone leaked memroy in helloworld.c and that has managed to make it into several branches. I want to correct that version in history on all the branches it managed to get into.

What is the net effect of reverting the file and attempting to check it back in? Obviously the 14 changes since then I would not want to lose?

Update: I am sure someone has faced this issue and I want to know what they have found works for them and why.

Am I being dense in thinking that the way branches and trunks are managed that I would have to visit the file in every context it exists in?

Answer 1

You can revert a single version. There may be conflicts, but you can resolve them.

Or you can fix the error in the current files and just commit them.

Answer 2

You don't want to modify the history. History is the sequence of edits that the file has gone through - not something you tamper with.

Simply update the head of every branch and the trunk with the memory leak fix and be on your way. Usually it's a good idea to reference in the new commit that you are reverting an old change. For example:

1. Person introduces leak in r100
2. Team makes changes in r101-r115
3. You make commit r116 with commit message: "Reverting r100 due to memory leak"

Good luck,

Answer 3

Even if you revert the change on the trunk the already created branches will have the problem in them - people would have to re-branch using your latest or just merge the fix from the trunk to their branches -which I think could be the best IF the issue is a real problem for any of them at all.

Answer 4

Why do you want to correct the history? That trick gets Star Trek in trouble all the time.

Better yet, make the change in a current version -- or revert the current version -- and commit it. Then merge the change into any branches.

Answer 5

You'll need to add the fix to each head, unfortunately. Although I'm sure there's technically a way of using svnadmin dump and dumpfilter to do this trick it would be a dodgy rewriting of history to say the least and require rebuilding your repository.

The latest tortoisesvn 1.6 has a really good revision graph which might let you work out where all the changes went.