76

I messed up on my SVN repository and now need to revert the entire repository from revision 28 to 24 and don't want to deal with diffs or conflicts. Is there a quick and simple way to do this? I've been able to revert back single files before fine with the merge command - but in this instance it wants to add all of the files back into the repository from revision 28 when all I really want to do is delete them.

I am using the command line on a linux box (bash).

Thanks

EDIT

Thanks for all of the help! I fixed it by:

svnadmin create /svnroot/<repo>.fixed
svnadmin dump -r 1:24 /svnroot/<repo> --incremental > dump.svn
svnadmin load /svnroot/<repo>.fixed < dump.svn

Then putting the old repo in a backup location and moving the repo.fixed to repo.

Thanks again!

  • 3
    Just wanted to say thanks for this. I'm learning svn and screwed up moving some directories around (turned out I had done it the other way for a reason!) and I wanted it gone. Your question saved me a lot of trouble. – AgentConundrum Sep 02 '09 at 14:25
  • Thanks, I believe this works, but takes so long when your repository has 10k+ revisions. :( – Amir Pashazadeh Nov 25 '14 at 17:14

14 Answers14

26

Check out svnadmin dump/load. It creates a text file with every version of your files. It may be possible to delete everything above/below a certain point and re-import it.

See for instance Migrating Repository Data Elsewhere

Justin Love
  • 4,397
  • 25
  • 36
  • 2
    I'm looking into this right now thanks. Of course, I was bound to accidentally type svnadmin dump without piping it so now my entire project is being written to stdin (and wont stop with ctrl+c)... I won't make that mistake again :p –  Dec 31 '08 at 03:36
  • OK; I am on the right track now, thanks! But how can I make it so it preserves my revisions? I wrote a perl script that, for 1 though 24 "svnadmin dump -r $i:$i+1 > file", then "svnadmin load < file" and it only commits revision 1. –  Dec 31 '08 at 22:17
  • 1
    Make sure you change the guid of your repository while reloading your backup when you change history. Otherwise you might use old workingcopies with a changed database and get misteriously broken revisions later (As they were build on deltas based on no longer existing versions). – Bert Huijben Jan 01 '09 at 00:54
25

A "reverse" merge may be what you need. See "undoing changes" section of svn book.

E.g. svn merge -r 28:24 [path to svn]

luapyad
  • 3,860
  • 26
  • 20
  • It does not delete the files that were created in 28. The problem is I added a bunch of files that I shouldn't of. Yes, I really screwed up. Manually chasing down what needs to be removed is out of the question. I just want to "delete" every reversion after 24. –  Dec 31 '08 at 03:10
  • 2
    Sorry - I must not quite have understood your problem. I have used the reverse merge to get rid of newly (but incorrectly) added files on several occasions...(but your case must be slight different?) (You cant normally delete revisions from the svn repo - only add new ones that repair the mistakes). – luapyad Dec 31 '08 at 03:24
  • All that you need to do is merge back, as the answer shows, and then check your project back in (`svn ci -m "Revering all changes back to revision X"`). It will still be possible to checkout the bad revisions, however, this will put the revision you want back at HEAD. – Niko Apr 15 '15 at 20:40
14

If you have access to the SVN server, you can just edit path/db/current, put the old revision number you want to revert to (here: 24) there, and remove no longer needed revision files (i.e. 25, 26, 27, 28) from path/db/revs/0/. At least this worked for me today, after I had accidentally removed a directory in the repository.

fuenfundachtzig
  • 7,952
  • 13
  • 62
  • 87
  • By far the fastest simplest thing to do, and I've used this trick in the past. It's a bad habit to get into, though, and I would never do this on a repo that was being used by anyone else, or had critical data in. It's better to go via the admin tools properly. – Tynam Nov 02 '10 at 11:34
  • I don't know everything that *could* happen, but I do know that it's *possible* for it to create trouble later, because I once had a problem with the next commit after doing exactly this. Having said that, I've done it successfully several times, and of course you took a backup of your repo first, right? (Of course, one obvious issue is that an old working copy's cache of the repo state won't match the actual repo after you do this, so *always* do a fresh checkout immediately after and work from that, or the mismatch is very likely to cause commit issues.) – Tynam Nov 10 '10 at 12:01
  • Oh, this is dirty … but seems to work. However, I had to run `svnadmin recover /path/to/repo` in order to be able to commit again. – lxg Jan 05 '15 at 11:49
  • It is worth noting that the files are only in `path/db/revs/0` if you have less than 1000 commits. If you have more than that, the files are in `path/db/revs/X`, where X is the commit number divided by 1000 – Michael Firth Mar 13 '19 at 15:49
13

If you really need to wipe 'evidence' that the files ever existed, you need to do the svndump/svnload actions described above.

In a 'normal' situation, where you made a mistake, you need to use reverse merge. This make sure that undoing the changes after r24 can also be reverted, diffed, etc.

The command below should work to undo your changes (you need to commit the result of the merge to reflect the merge in the repository)

svn merge -r 28:24
Sander Rijken
  • 21,376
  • 3
  • 61
  • 85
  • 1
    Haha, well I could go in to detail on how this is not a "normal" situation but would rather not embarrass myself further –  Dec 31 '08 at 22:35
  • 1
    The 'abnormal' situation would be if you committed something secret, like a file containing a password or something like that; you'd want that removed completely. Last news on this is something was getting started on "svn obliterate" – Sander Rijken Feb 25 '09 at 21:44
6

If you do not avail admin rights then you cannot obliterate any old revisions BUT you can still hide them extremely well with just one amazingly simple "svn copy" command (nickf and JesperE already mentioned this but in a rather cryptic way)

svn delete protocol://svnserver/some/resource
svn copy protocol://svnserver/some/resource@24 protocol://svnserver/some/resource

And that's it, revisions 25 to 28 have completely disappeared from svn log. It's not a hack at all, it is a safe and (barely...) documented feature.

If "resource" is a directory then you must strip it from the last URL:

svn copy protocol://svnserver/some/directory@24 protocol://svnserver/some/

(otherwise you would copy it inside itself)

MarcH
  • 18,738
  • 1
  • 30
  • 25
  • If the `svn copy prot://srv/path/proj ...` command gives you an error like "svn: E170000: ... isn't in the same repository as ..." then you can work-around it by doing a `svn checkout prot://srv/path/proj@321 coolver` then `svn copy coolver/proj prot://srv/path/` ; # ftw! – MarkHu Feb 13 '15 at 09:16
4

For anyone using TortoiseSVN, the solution is simple:

  • view change log
  • right-click the revision you want to roll back to...
  • ...select "Revert to this revision"
  • commit your changes

This method preserves the version history (i.e. all of the revisions that you reverted).

Paul Suart
  • 6,505
  • 7
  • 44
  • 65
  • I used more or less what you said here because the version history was preserved, but what I did was delete the source code of my working copy and then selected "Update items to revision" (because "revert to this revision" didn't quit the files that were created after the revision). Great solution for tortoiseSVN users :) – Ignacio Rubio Sep 02 '14 at 14:01
  • I am pretty sure the question was about deleting the history – MarcH Sep 11 '14 at 18:59
  • This option does not exist in TortoiseSVN, at least not in 2018. – Rockin4Life33 Dec 18 '18 at 22:16
3

You can do a new checkout of a particular revision. http://svnbook.red-bean.com/en/1.1/re04.html

svn co path/to/my/repo -r 24
nickf
  • 537,072
  • 198
  • 649
  • 721
  • I have done that already, but it refuses to commit back to the repository as a new revision. Is it possible to do that? I.e. make revision 29 to a copy of revision 24? –  Dec 31 '08 at 02:45
  • Yes. The svn copy command can do repo -> repo copies. Check "svn help copy" for the exact syntax. – JesperE Dec 31 '08 at 18:06
2

If the folder structure of your application hasn't changed, checkout the old revision and replace the .svn folders from the latest revision into the checked out old revision. Now you can commit the "older" version.

neesh
  • 5,167
  • 6
  • 29
  • 32
  • 2
    Sounds like a hack to me to be honest. – Sander Rijken Dec 31 '08 at 19:39
  • Unfortunately, the folder structure changed significantly otherwise I would just manually delete what needed to be deleted. Thanks for the input though. –  Dec 31 '08 at 22:24
  • 1
    I agree it's a hack; but this is a one off situation so I am not sure if I would look for the most elegant solution. Something quick and easy would suffice. – neesh Dec 31 '08 at 22:26
1

If you really want to completely remove files from the repository, you need to do an svndump into a file, filter out the revs and/or file paths you don't want, make a new repo, and svnload the filtered dump into the new repository. You'll want to carefully read the SVN book section on repository maintenance before you do any of this, and make sure you don't remove the existing repo until you're sure the new one has the stuff you want.

genehack
  • 136,130
  • 1
  • 24
  • 24
1

Could you svn del the topmost directories, then svn copy them:

svn copy svnurl@version svnurl
oers
  • 18,436
  • 13
  • 66
  • 75
Lyndon
  • 11
  • 1
0
Example:
    Rev 100 all is working great        
    Rev 101 somebody really corrupted the dir structure and / or merged in bad changes, etc.
    Rev 102 You delete /trunk
    Rev 103 You copy /trunk@100 to HEAD
        You now have a /trunk that reflects only Rev 100 and 103. Not 101 or 102.

svn del svn://[RepoName]/trunk -m "removing issue in HEAD"
svn copy svn://[RepoName]/trunk@100 svn://[RepoName]/trunk -m "Copy of correct revision of trunk to HEAD"
Mazrick
  • 1,149
  • 8
  • 10
0

I hate to say this, but that is a situation where I've found myself using backups of my svn repository.

Can you copy files of a certain revision to a new directory within the repository?

  • Backup SVN sounds silly it itself, but it sounds like that is something I should of done in the first place :/ –  Dec 31 '08 at 03:13
  • I've had svn repositories get corrupted, and it is not fun. I do backups frequently and put copies in a safe deposit box at the bank. –  Dec 31 '08 at 03:31
  • Backing up is a good practice, but restoring from backup in this situation shouldn't be necessary. – Sander Rijken Dec 31 '08 at 19:35
0

here is how I would start to do it. Brutal, yes, but its the only thing guaranteed to completely ignore collisions and keep revisions history intact.

  cd /scratchdir 
  svn co -r good svn://repository
  cd /hosed_project
  svn up -r HEAD
  cat >> /tmp/cp.sh 
  ORIG=$1
  TARG=$( echo $ORIG | sed 's/\/scratchdir\///' ); 
  cp $ORIG /hosed_project/$TARG;
  ^D
  chmod u+x /tmp/cp.sh
  find /scratchdir -not -wholename "*/.svn*" -exec /tmp/cp.sh {} \;

Note, this is not the "normal" way IMO, the normal way is to create a branch from an old version, and then merge that branch back in to the head. ( at least, that's how It used to work )

Edit: the above code is untested, do NOT run it verbatim

Kent Fredric
  • 56,416
  • 14
  • 107
  • 150
0

I'm not entirely sure if this work as I haven't used it in a live production yet, but I just now tried on a test repository (I copied one of my production ones) and it seems to work.

When you're in your repository, use the following command:

svn update -r 24 trunk

Where 24 is the revision number, and trunk is the file/folder you'd like to update (or restore, in this case) to said revision number.

In my test, several files were updated and (re-)added, and after doing a commit I did not receive any warnings whatsoever. I then modified a file with some dummy text and tried yet another commit, and only said file popped up on the modified list. So it seems to work rather well!

Again, I didn't use this before in live productions, so if I'm wrong please advice. I'd love to know if this is the way to go, too, because I can see myself needing this in the (near) future.

-Dave

  • This only updates your working copy to this older version, and provides no way to commit this as noted above. – Sander Rijken Dec 31 '08 at 19:36
  • Are you sure? I have tried this in a test environment, and it seemed to commit fine? I could be wrong though. –  Jan 18 '09 at 14:21
  • If the file had revisions after r24 and you modify it, then svn will fail to commit any changes to it and will demand that you update to HEAD first – Wim Coenen May 13 '09 at 00:54