Deleting a revision from TortoiseSVN

Question

When I commit code into my company's Subversion repository, I often have several files that need to be checked in. Often times, I want to check them in (commit them) separately, because I like to group similar files together.

By default, TortoiseSVN opens up the Commit dialog window with all the files selected. If I only want to commit a few of those files, I have to "unselect all" the ones I don't want to commit, add my comments/notes, and then perform the commit.

Every now and then I accidentally forget to "unselect all" and wind up committing all the files. If it was not my intention to commit all the files, I'd like to think I'd be able to go in and delete the revision and start over. Keep in mind, I don't want to delete the files from the revision, I just want that revision to have not existed.

Let's say the accidental commit resulted in checking in 12 files and the revision was revision number 9651. If I meant to check in 2 files, instead of 12, I'd like to delete that revision so I can check in the 2 files properly.

From what I can see, one option is to "Revert changes from revision 9651". But what that does is it keeps 9651 in the repository and rolls back affected the code to its previous state. Which essentially means that you'd lose the changes you've just made. You could then "Update to item revision 9651" and then repeat the commit process.

But is there another way to do this, a way to delete the revision from the repository AND avoid having to rollback the affected code?

Answer 1

Apparently it's not implemented: http://blog.projectnibble.org/2008/03/01/subversion-obliterate-the-forgotten-feature/

There is a work around, see the article. I think You need server access, though.

Answer 2

IMHO the best approach to handle this is to avoid it. Better you get accustomed to work at only one thing at once, compile it, test/debug it, and when it works, commit all changes immediately. So you can check in all changed files, and most times have to enter just one comment to SVN. Don't start with the next micro-feature until you committed your work, whenever possible. Committing only portions will increase the chance that someone else gets a 'build break' after an update, so don't do this!

Answer 3

I recommend using changesets to first group modified files together and then commit them (at least when using SmartSVN). Unfortunately, this does not work, if files were changed that way, that some lines should be stored in this changeset/commit, other lines in another one.