世间大路多有坑,就怕自己掉进去。从进了公司后丢弃了之前学过的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...