Reputation: 44395
I have found various examples of how to revert an SVN commit like
svn merge -r [current_version]:[previous_version] [repository_url]
or
svn merge -c -[R] .
But neither of them seems to work. I tried those commands and checked the files that were changed by hand.
How do I revert a commit with revision number 1944? How do I check that the revert has been done (without looking in the actual file to the changes have been reverted)?
Upvotes: 346
Views: 625099
Reputation: 141672
First, undo the changes made in revision 1944.
> svn merge -c -1944 .
Second, check what is about to be commited.
> svn status
Third, commit version 1945.
> svn commit -m "Fix bad commit."
Fourth, look at the new log.
> svn log -l 4
------------------------------------------------------------------------
1945 | myname | 2015-04-20 19:20:51 -0700 (Mon, 20 Apr 2015) | 1 line
Fix bad commit.
------------------------------------------------------------------------
1944 | myname | 2015-04-20 19:09:58 -0700 (Mon, 20 Apr 2015) | 1 line
This is the bad commit that I made.
------------------------------------------------------------------------
1943 | myname | 2015-04-20 18:36:45 -0700 (Mon, 20 Apr 2015) | 1 line
This was a good commit.
------------------------------------------------------------------------
Upvotes: 55
Reputation: 97355
Both examples must work, but
svn merge -r UPREV:LOWREV .
undo range
svn merge -c -REV .
undoes a single revision, in your case REV would be 1944, i.e. the revision you wish to undo.
in this syntax - if current dir is WC and (as in must done after every merge) you'll commit results
Do you want to see logs?
Upvotes: 492
Reputation: 1526
Note that the svn merge
command reverts a commit in the sense of having another commit undoing your changes, but keeping your wrong commit in the history.
In the case you are a Subversion system administrator (with command line access) and you have to revert a very big mistake (for example, someone committed something that should not be committed for no reason in the world), and if you want to try to completely drop a commit at any cost, even at the risk of destroying the repo:
First of all identify your repository on your server's filesystem.
Let's assume that the pathname is /repo
. But it may be /home/svn/myrepo
or something like that.
The filesystem structure should be something like this:
$ ls -la /repo
total 16
drwxr-xr-x. 6 svn svn 86 10 feb 2020 .
drwxrwx---. 145 svn svn 4096 22 giu 16.14 ..
drwxr-xr-x. 2 svn svn 54 10 feb 2020 conf
drwxr-sr-x. 6 svn svn 253 17 giu 11.25 db
-r--r--r--. 1 svn svn 2 10 feb 2020 format
drwxr-xr-x. 3 svn svn 4096 10 feb 2020 hooks
drwxr-xr-x. 2 svn svn 41 10 feb 2020 locks
-rw-r--r--. 1 svn svn 229 10 feb 2020 README.txt
Let's also assume that your user is called svn
like in the above example.
NOTE: if you don't know what this is talking about, you probably have not your own Subversion server and this answer may be not useful for your case. Please try other answers (where you just need to have the URL of the server, without physical access).
Let's assume that your wrong revision is 100
and your correct version is 99
:
svnadmin dump -r 1:99 /repo > export.dump
Create a backup of your repository and initialize it again:
mv /repo /repo.bak
mkdir /repo
svnadmin create /repo
svnadmin load /repo < export.dump
Now, make sure to fix your permissions with the right user:
chown -R svn:svn /repo
Is everything working? That's all! Good for you!
BUT at this point there are interesting chances you have destroyed your whole repository. For example, you may no longer be able to checkout, or, your Subversion web application (Phabricator?) may scream with weird error messages, or, you could have killed a thousand kittens by mistake in the process.
If something goes wrong stay ready with your disaster recovery:
If a disaster happen:
mv /repo /repo.fail
mv /repo.bak /repo
Hoping to be useful.
Upvotes: 0
Reputation: 1485
Very old thread, however there is no answer for Intellij. To revert a single commit:
Go to: Subversion -> Integrate Directory...
Upvotes: 0
Reputation: 3630
svn merge -r 1944:1943 .
should revert the changes of r1944 in your working copy. You can then review the changes in your working copy (with diff), but you'd need to commit in order to apply the revert into the repository.
Upvotes: 72
Reputation: 146
If you want to completely remove commits from history, you can also do a dump of the repo at a specific revision, then import that dump. Specifically:
svnrdump dump -r 1:<rev> <url> > filename.dump
The svnrdump command performs the same function as svnadmin dump but works on a remote repo.
Next just import the dump file into your repo of choice. This was tested to worked well on Beanstalk.
Upvotes: 1
Reputation: 13063
If you're using the TortoiseSVN client, it's easily done via the Show Log dialog.
Upvotes: 143
Reputation: 31
svn merge -c -M PATH
This saved my life.
I was having the same issue, after reverting back also I was not seeing old code. After running the above command I got a clean old version code.
Upvotes: 2
Reputation: 21
While the suggestions given already may work for some people, it does not work for my case. When performing the merge, users at rev 1443
who update to rev 1445
, still sync all files changed in 1444
even though they are equal to 1443
from the merge. I needed end users to not see the update at all.
If you want to completely hide the commit it is possible by creating a new branch at correct revision and then swapping the branches. The only thing is you need to remove and re add all locks.
copy -r 1443 file:///<your_branch> file:///<your_branch_at_correct_rev>
svn move file:///<your_branch> file:///<backup_branch>
svn move file:///<your_branch_at_correct_rev> file:///<your_branch>
This worked for me, perhaps it will be helpful to someone else out there =)
Upvotes: 2
Reputation: 1282
I tried the above, (svn merge
) and you're right, it does jack. However
svn update -r <revision> <target> [-R]
seems to work, but isn't permanent (my svn is simply showing an old revision). So I had to
mv <target> <target backup>
svn update <target>
mv <target backup> <target>
svn commit -m "Reverted commit on <target>" <target>
In my particular case my target is interfaces/AngelInterface.php
. I made changes to the file, committed them, updated the build computer ran the phpdoc compiler and found my changes were a waste of time. svn log interfaces/AngelInterface.php
shows my change as r22060 and the previous commit on that file was r22059. So I can svn update -r 22059 interfaces/AngelInterface.php
and I end up with code as it was in -r22059 again. Then :-
mv interfaces/AngelInterface.php interfaces/AngelInterface.php~
svn update interfaces/AngelInterface.php
mv interfaces/AngelInterface.php~ interfaces/AngelInterface.php
svn commit -m "reverted -r22060" interfaces/AngelInterface.php
Alternatively I could do the same thing on a directory, by specifying . -R
in place of interfaces/AngelInterface.php
in all the above.
Upvotes: 1
Reputation: 301
The following will do a dry run, as it says. HEAD being current version, PREV is previous, then the path to your file, or committed item:
svn merge --dry-run -rHEAD:PREV https://example.com/svn/myproject/trunk
If the dry run looks good, run the command without the --dry-run
Verify the change in revision and re-commit. To browse for version numbers try:
svn log
Upvotes: 10
Reputation: 460
F=code.c
REV=123
svn diff -c $REV $F | patch -R -p0 \
&& svn commit -m "undid rev $REV" $F
Upvotes: 5
Reputation: 8874
It is impossible to "uncommit" a revision, but you can revert your working copy to version 1943 and commit that as version 1945. The versions 1943 and 1945 will be identical, effectively reverting the changes.
Upvotes: 28