SVN服务器还原到原来版本，核心思路是提交一个新版本把代码回滚到旧状态，而不是直接删掉历史记录，具体操作是用svn merge反向合并再svn commit，或者用svn update -r只回退本地工作副本，整体不难，但有几个关键细节容易出错。
svn服务器还原到指定版本的常用方式
我在维护项目的时候，经常遇到同事问“SVN服务器能不能一键回到昨天的版本”，说实话，SVN不像某些工具那样有“时光机”按钮，它讲究的是通过版本号来操作，我们得先分清你要回退的是服务器仓库里的代码，还是你自己电脑上的工作副本,这两个场景用的命令完全不同。
svn update 回退工作副本
如果只是你自己本地代码改乱了，想回到某个历史版本,最简单。
- 先查看提交日志,确定要回退的版本号。
- 在项目目录执行
svn log -l 10,能看到最近的10条提交记录。 - 然后执行
svn update -r 100,这里的100就是你要回去的版本号。 - 这样操作后，只有你本地代码变了，服务器的仓库没有任何变化,别人不受影响。
这个命令适合急着对比代码逻辑的人，但有个坑：如果之后你改了代码再提交，SVN会基于混合版本处理，容易产生冲突，所以本地回退更多是临时救急用。
svn merge 回退服务器仓库
要让服务器本身也回到原来的版本，正确姿势是反向合并，这一步才是真正意义上的“服务器还原”。
- 先查看完整日志，找到出问题的版本区间，比如当前是
rev 120，你要回到rev 100。 - 执行
svn merge -r 120:100 .，注意末尾有个点,表示当前目录。 - SVN会计算从102到120之间的所有差异，然后反向应用到你的工作副本上。
- 检查完本地改动没问题后，执行
svn commit -m "回退到r100"。 - 提交成功后，服务器上的版本号会变成121,但代码内容和r100完全相同。
所以你看，SVN服务器不能真正“抹掉”后面的版本，而是用新版本去覆盖代码内容,这是SVN作为集中式版本控制系统的核心逻辑。
svn switch 与异地备份恢复
还有一种场景是配置文件或整个仓库损坏了，客户端完全没法访问,这时候需要用底层工具。
- 如果你有
svnadmin dump导出的备份文件,可以直接恢复整个仓库。 - 停掉SVN服务，把备份的dump文件通过
svnadmin load导入到新仓库目录。 - 这属于物理恢复，适合灾难场景,操作前记得备份当前数据。
svn switch一般用于切换分支路径恢复，平时很少用来回退，但有些人会用它切换到某次提交对应的分支，也算一种间接方式，不过我更推荐前两种,简单直接。
svn服务器怎么还原成原来的版本而不影响他人
多人协作时，最怕你一回退，别人刚提交的代码全没了，这里我分享一套我能保证不踩雷的流程，行业共识认为，SVN回退的核心是“保留历史，覆盖现状”，所以你完全不用怕把别人的东西搞丢,只要按顺序来。
回退前先查看提交日志和版本差异
动手之前，先搞清楚一个问题：你想回退到什么状态？是回退到自己出错的前一个版本,还是回退到某次合并之前？
- 用
svn log -v查看每个版本改动的文件列表。 - 用
svn diff -r 120:100对比两个版本之间的具体差异。 - 重点确认在
rev 100到rev 120之间，有没有其他人提交的重要代码。 - 如果别人的代码恰好在你需要回退的区间内，就得上报团队,一起想办法处理。
这一步是防患于未然,不能跳过去。
用svn merge来回退并提交的完整步骤
假设确认可以回退,下面是不会影响别人的常规操作顺序。
svn up先把工作副本更新到服务器最新版,避免基于旧版本做回退。svn merge -r HEAD:100 .将最新版本回退到rev 100。svn status查看改动列表,确认回退涉及的文件。- 手动打开几个关键文件,确认核心代码确实回到了目标版本。
- 执行
svn commit -m "revert to r100 due to requirement change"。 - 提交后，历史记录里依然能看到120之前的版本,只是在最新版上代码回到了100的样子。
这么做的好处是：如果回退后又后悔了，可以再用相同方式把其他版本合并回来，因为历史没被破坏,所有操作都可追溯。
回退后如何同步给团队成员
回退提交后，团队成员需要执行一次svn update才能看到新状态，这点看似简单,但很多人会忘记。
- 让团队所有人先
svn commit自己的本地修改，再svn update。 - 如果某人本地有未提交的改动，且这些改动涉及回退的文件,SVN会强制冲突。
- 解决办法是让这个人先备份自己的改动，然后执行
svn revert再更新。
服务器回退只改了仓库，不代表每个人电脑上的代码自动变了，你必须明确通知大家更新,不然就会出现在本地旧代码上继续开发的情况。
svn服务器还原时容易踩的坑
我用SVN几年了，见到的翻车现场不少，下面这些坑,几乎每个回退场景都会出现。
直接update -r 导致混合版本问题
很多人图省事，直接在服务器某台机器上执行svn update -r 100，然后觉得完事了，结果代码库处于混合版本状态（本地是r100，服务器是r120）,下次提交可能会意外改到别的目录。
- 混合版本会导致
svn status显示一堆不存在的修改。 - 同时会影响
svn merge计算差异的准确性。 - 解决方法是回退后立刻
svn up回到最新版本。
所以对于服务器仓库，我从不建议用update -r，必须用merge。
没有权限或认证失败
SVN服务器通常设置了读写权限，如果你用的账号只有只读权限，执行svn merge会直接报Authorization failed。
- 先检查仓库的
authz文件里,当前用户对该路径是否有写权限。 - 确认能写再执行回退操作。
- 如果是通过
svn+ssh方式,还要检查服务器上的用户角色。
遇到权限问题，只能找管理员给临时权限,用完后收回去。
冲突无法解决时怎么处理
反向合并时，如果当前工作副本里有未提交的本地修改，很容易产生冲突，SVN会在文件里标记<<<<<<<和>>>>>>>。
- 手动打开文件，保留需要的内容,删除标记符号。
- 用
svn resolved标记合并冲突已解决。 - 再执行
svn commit
完成回退。
有时候冲突文件多到头皮发麻，那就要考虑用svn revert放弃所有本地改动，重新合并，只要你不怕丢代码,这反而是最干净的方式。
其他场景：svn服务器代码回滚的替代方案
除了用svn merge,有些特殊需求还能走别的路。
备份还原法（适用于灾难恢复）
如果你有完整的仓库备份，比如svnadmin hotcopy做出来的快照，或者每天定时备份的dump文件，那么回滚就是整体替换的事。
- 停止SVN服务。
- 把旧的仓库目录改名备份。
- 把恢复用的仓库目录复制到正式路径。
- 启动SVN服务,所有人重新更新代码。
这种方式恢复速度极快，但有个代价：从备份时间点到故障之间提交的版本会丢失，所以只能用在比如误删整个分支、服务器被入侵的极端情况。
使用SVN管理员权限强制回退
普通用户只能回退自己改的代码，遇到全局性错误，比如不小心提交了带密码的文件或数据库脚本,管理员能直接操作。
- 管理员用超级用户账号执行
svnadmin命令。 - 对需要删除的版本，可以用
svnadmin的工具间接处理历史。 - 但这种操作风险很高，容易导致仓库编号不连续,不建议常规使用。
业内专家指出，正常企业里99%的回退需求都不需要动底层数据，用svn merge就能解决,强制回退历史版本反而可能让团队混乱。
svn服务器还原版本常见问题解答
问：svn服务器还原来得及吗？如果已经提交了错误版本怎么办？
来得及，SVN没有“撤回”机制，但你可以用svn merge -r HEAD:目标版本 .生成反向修改，再提交一个修正版本，这样服务器内容就回到了目标状态，原错误版本依然留在历史记录里，可以通过日志看到,不影响正常使用。
问：svn merge回退和svn update回退有什么区别？svn update -r只改变本地工作副本的版本，不修改服务器仓库；svn merge会计算差异并应用到本地，然后通过svn commit把回退结果推送到服务器，从而改变仓库内容，要让服务器还原,必须走merge加commit这条路。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/763332.html
