The first case: The change was not committed (commit). In this case, the previous modification can be canceled using SVN revert. SVN revert usage is as follows: # svn revert [-R] Something where something can be a relative path (either a directory or a file) or an absolute path. When something is a single file, the direct svn revert something is OK; when something is a directory, you need to add a parameter-R (Recursive, recursive), otherwise it will only change something this directory. In this case, you can also use the SVN Update command to cancel the previous modification, but it is not recommended. Because SVN update is going to connect to the warehouse server, it's time consuming. Note: The SVN revert itself is inherently dangerous because it is intended to discard uncommitted modifications. Once you have chosen recovery, Subversion has no way to retrieve uncommitted modifications. The second case: The change has been committed (commit). In this case, use the SVN merge command to roll back. The procedure for rolling back is as follows:1to make sure we get the latest code: SVN update assumes the latest version number is 28. 2, and then find out the exact version number to roll back: SVN log [something] assumes that the version number to rollback is 25 based on the SVN log log, where the something can be a file, a directory, or an entire project. If you want to know more about the situation, you can use SVNdiff-R -: -[Something]3, roll back to version number 25:SVN merge-R -: -something for the sake of insurance, re-confirm the results of the rollback: SVNdiff[something] found correct, submit. 4, commit rollback: SVN commit-M"Revert revision from R28 to R25,because of ..."The post-commit version becomes 29. Summarize the above actions as follows: three1. SVN update,svn Log, find the latest version (latest revision)2Find the version number you want to roll back (Rollbak revision)3. Roll back with svn merge: SVN merge-r: something
SVN Code rollback command