SVN中万恶的replace

世间大路多有坑，就怕自己掉进去。从进了公司后丢弃了之前学过的git改用svn，也一直使用的都很顺利，没出现过什么大问题。但是！！！今天，小组分享上次升级的问题总结，有个小伙伴分享了一个关于svn的坑，吓得宝宝再不敢随意操作。
事情是这样的，这个哥们要更新一个文件，他用的是phpstorm的编辑器，可以直接将代码同步到svn，这个时候他从外部拉了一个文件到phpstorm（这个文件项目中原来就有），phpstorm弹窗提示他后就直接把原来的文件删除了，新加了这个文件。然后svn同步更新，提示他先删除了原文件，改用新文件，是否确认提交，后来这哥们就点击了“YES”。。。后来就惨了，svn这个时候提交状态是replace，就是说该文件被替换了。提交之后，万恶的源头就来了，以前操作过的日志记录都不会显示了。不会显示了。。。不会显示了。。。用revision graph可以看到所有历史, 只是在replace处是断裂的。也就是说替换的效果是重新开启一个文件的更改记录, 隐藏之前的记录。
不知道各位看明白了这个问题了么，我在简单的描述一下：
如果对文件做SVN Delete操作，然后再SVN Add一个同名文件，此时提交的操作被视为一次Replacing。文件的所有历史记录从此断裂，查看日志只能看到Replacing之后的日志。

那遇到这种情况该怎么办呢？我们要去恢复，但是我们要求恢复SVN版本库中的原文件及日志不只是恢复成之前的文件。解决方法如下：

以文件test.txt举例，假设版本48中有人做了Replacing操作，替换了原有文件。

冷静，在文件所在文件夹空白处点击右键，SVN子菜单中选择Repo-browser。

选择文件test.txt，右键选择Delete。

然后再切换到Replacing之前的版本，例如这里是版本47.

在版本47的视图中，文件又出现了，这个文件就是Replacing之前的文件。要还原这个文件，我们对这个47版的文件做Copy to操作。如图，弹出的路径默认为文件当前路径，不用修改，直接确定，输入日志然后提交。

好了，我们的文件成功还原到了历史版本。

本文解决方案参考：https://my.oschina.net/zerofl...