40

The latest revisions in my code repo has been corrupted and has destabilized my app. I want to revert to an earlier revision.

But I don't want to simply use 'revert' on my working copy; I actually want to delete my head revision and several revisions prior in my repo, thereby 'reverting' my repo to an earlier revision, which would become the head revision. Anyone know how I would do this?

Sathyajith Bhat
  • 61,504
  • 38
  • 179
  • 264
  • 2
    You can't really delete old revisions, all you can do is reverse the changes, and commit that, as mentioned by Felix. Interesting sidenote, Git (as well as other version control solutions) actually does allow you to truly delete revisions.. – davr Jan 13 '10 at 20:51
  • 4
    Yes you can, you just need access to the SVN repository with svnadmin. See my answer below. – martin Jul 26 '11 at 07:45
  • 1
    davr is technically right. What you describe is dumping all revisions except the bad ones, then dumping this on top of the old repo. In my mind that's not really the same thing as 'deleting' a revision. – Sirex Jul 26 '11 at 09:42

7 Answers7

85

This worked for me. Given that you have revision 1234 as the HEAD and you want to revert last three commits:

svnadmin create newrepo
svnadmin dump -r 0:1231 repo | svnadmin load newrepo
mv repo oldrepo
mv newrepo repo
martin
  • 1,051
  • 1
  • 7
  • 6
  • 16
    +1. You're the only one who both understood the question and gave a specific answer. – Matthew Flaschen Jul 12 '12 at 22:58
  • 7
    This is technically the right answer. It should be pointed out, however, that this, apart from possibly being rather complicated to do, will also invalidate all checked-out copies - so you'll need to alert anyone who is also using the repo. – sleske Dec 17 '12 at 16:18
  • 2
    quick and easy and to the point and actually what the poster asked for. – unc0nnected Apr 11 '13 at 03:23
  • 9
    As long as you make sure to also copy the repository UUID over to the new repo (see "svnadmin setuuid", copying from the UUID in "svn info" on the old repo), only checkouts updated to the revisions you are cutting out will be invalidated. – Bryan Petty Jun 13 '13 at 15:27
  • +1. can you delete file versions that you dont need anymore in order to trim the repo? like "if the file has 100 revisions, delete 40-60" or this messes up the change sets? – Tomer W Jan 14 '14 at 18:41
  • See also detailed example at http://stackoverflow.com/questions/5566327/delete-all-traces-of-a-svn-commit – Vadzim Feb 29 '16 at 07:48
  • 2
    On the new repos you may need to fix file permissions or copy in files in the hooks/conf directories – AdamS Apr 11 '18 at 14:23
  • Perfect! @sleske: This note is very useful. The solution for working copies. 1) make an export from the actual working copy. 2) Check-Out new working-copy from the reverted version. 3) copy the exported working-copy to the checked-out folder (actual working-copy). – raiserle Oct 01 '18 at 07:23
  • Then after restoring the previous UUID as @Bryan Petty said, move to a newly created temp directory, check out the new repo in a new working copy in temp, delete the .svn hidden directory from the original repo, copy the .svn hidden directory from the new working copy in temp, remove temp, do an svn st from the original working copy to check every thing is fine. This what I did, since check out from the original working copy did not work (many conflict I did not understand and could not solve). It’s a good idea to make a script of all of it. – Hibou57 Apr 26 '20 at 12:08
13

Maybe this link helps you:

http://www.sampablokuper.com/2009/03/27/svn-revert-to-revision/

Quote:

  1. Change to the top directory within your working copy (assuming you want to roll back the whole of the working copy).

  2. run svn revert to revert your working copy's files to the state they were in when you last committed/checked out.

  3. run svn status -v to see which revision number your working copy now corresponds to (it's the highest revision number in the list that svn status -v produces).

  4. run svn merge -rXX:YY where XX is the number you obtained in the previous step and YY is the number of the revision you want to revert to.

  5. Done! The possible exception to this is that files in your working copy that didn't exist when revision YY was originally made, will still be there, because by default svn doesn't remove things. If you want to get rid of them, run a svn del [filename] on each of them.

  6. Well done! Now play with your working copy as though all those intermediate edits had never happened . And when you're ready to commit your efforts, just use svn commit as usual!

Community
  • 1
Felix
  • 4,441
  • 1
  • 19
  • 10
  • 1
    In Windows Os, option #4 run `svn merge -rXX:YY .` Remember to put a dot at the end of line to reference the current directory. And in TortoiseSVN, there is an option to reverse merge. – Shantha Kumara Mar 01 '12 at 08:15
  • 4
    This does not actually revert to "earlier revision, which would become the head revision". It doesn't make the older revision the HEAD. Rather, it creates a new HEAD. See martin's answer. – Matthew Flaschen Jul 12 '12 at 23:34
  • I modified the answer to include Shantha's remark about the trailing period. This is the same on *nix as well. – Mike Kormendy Feb 01 '17 at 17:48
6

For me (VisualSVN, 30-HEAD) works this :

  del C:\Repositories\MyRepo\revs\0\30
  del C:\Repositories\MyRepo\revs\0\29
  del C:\Repositories\MyRepo\revs\0\28
  del C:\Repositories\MyRepo\revprops\0\30
  del C:\Repositories\MyRepo\revprops\0\29
  del C:\Repositories\MyRepo\revprops\0\28
  echo 27 > C:\Repositories\MyRepo\db\current
Anton Golikhoff
  • 61
  • 1
  • 1
  • How is this better than other answers? – Toto Feb 02 '18 at 13:38
  • 1
    It's much faster. – Anton Golikhoff Feb 02 '18 at 13:43
  • Any working copies already updated to the revisions being deleted will become invalid if they are not reverted to the last kept revision. – jimp Mar 09 '20 at 02:31
  • Also, this used to be a very simple solution, but FSFS v5 repos with [`rep-cache.db`](https://www.reddit.com/r/svn/comments/2hc9f1/repcachedb/) will now cause a cache timestamp conflict on commit. That file can be removed and it will start over, but a `dump|load` might be the safest choice now. – jimp Mar 09 '20 at 02:33
  • 1
    This answer is incomplete. When I simply delete the files in "revs" and "revprops" but keep the "current" file the same, then the deleted revisions still show up in the log when click on "Show log" in the Checkout dialog when checking out a new working copy from this repository, **including author, date and message**. So this information must be stored somewhere outside of those files. This also happens after deleting rep-cache.db and rep-cache.db-journal from the repository. – Niko O Jun 02 '22 at 12:14
  • @NikoO You must update or remove the local working copy cache: `Settings->Log Caching->Cached Repositories` – Andry Sep 13 '22 at 02:46
5

You can use dump / load for this purpose.

You could also use svnsync to make a backup to some revision.

If you have a big repository, it take time.

Bac From Vietnam
  • 51
  • 1
  • 1
5

I know this is an old question, however, I've just found how to do this with Windows/TortoiseSVN.

As a comment suggested, you can't "delete" a revision, but what you can do is make a more current revision that is the same as the revision you want to revert to.

  1. Checkout the HEAD of the repository for the directory you want to revert the revision from.
  2. Load the "Show Log" view in TortoiseSVN for the highest level directory you want to revert (e.g. "Trunk").
  3. Right-Click the revision you want to remove NOTE: this is the revision you want to remove, not the one you want to revert to.
  4. Select "Revert changes from this revision".
  5. Click "Yes" at the prompt.
  6. Update the checkout as normal, but to "HEAD".
  7. Commit it back.

You will then to go to everyone else who has it checked out and get them to update and make sure to remove any new files.

Also, you'll need to make sure that everyone knows what that revision was and potentially update the description.

Martin
  • 173
  • 1
  • 7
  • how is that different from the normal "revert" procedure? – Tomer W Jan 14 '14 at 18:44
  • A Revert just changes your working copy to what is in the repo... this is how to make the HEAD of a report reflect the state of any previous commit. – Martin Jan 15 '14 at 00:11
  • 1
    Thanks for this - Doing this the tortoise SVN way was just what I needed to revert an erroneous commit :) – Dr. ABT Jan 23 '15 at 21:30
  • There is also a context menu entry "**Revert to this revision**" in the Log window. – Uwe Keim Feb 01 '17 at 08:25
0

Go to the terminal and navigate to the svn repsitory: now type

svn update -r "revision number you want to revert"

Mohd Ikram
  • 1
  • 2
    Welcome to Super User! Please read the question again carefully. Your answer does **not** answer the original question. OP says "I don't want to simply use 'revert' on my working copy" – DavidPostill Jun 15 '16 at 09:01
0

If you want completely delete revisions from the history between other revisions and don't want the revisions from shift upon dump loading like:

------- Committed new rev 1 (loaded from original rev 2) >>>
...
------- Committed new rev 2 (loaded from original rev 3) >>>
...

Then you can just replace all blobs in the dump for each revision <N> from:

Revision-number: <N>
... <blob> ...

to:

Revision-number: <N>

or

Revision-number: <N>
Prop-content-length: 0
Content-length: 0

But to make it compatible, for example, with https://sourceforge.net/p/PROJECT/REPO/commit_browser UI (otherwise it will stuck on loading):

Revision-number: <N>
Prop-content-length: 56
Content-length: 56

K 8
svn:date
V 27
1970-01-01T00:00:00.000000Z
PROPS-END

This will leave all these revisions as empty and other revisions on the same places upon dump loading.

The TortoiseSVN GUI show log will show them as (none).

Andry
  • 101
  • 4