防止 SVN 中其他提交者覆盖文件
当一位开发人员打开文件 A 并开始编辑它时，就会出现问题。另一位开发人员也已写入文件 A 并提交到主干。
第一个开发人员 svn-updates 和 file-A 现在已在他的工作目录中更新，但他已经开始基于上次修订版处理 file-A 了。如果她保存文件然后提交，它将覆盖其他开发人员所做的所有更改。
在这种情况下，可以采取什么措施来预防呢？有什么好的工作流程吗？ DVCS 能否帮助解决此类冲突？
The problem arises when one developer has a file-A open and begins to edit it. Another developer has also written into file-A and committed into trunk.
The first developer svn-updates and file-A is now updated in his working directory but he has already started working on file-A based on the last revision. If she saves the file and then commits, it will overwrite all changes made by the other developer.
In this situation, what can be done to prevent it? Any good workflows? Will a DVCS help resolve this type of conflict?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
进行 SVN 更新应该要么优雅地将其他开发人员的更改合并到第一个开发人员的工作副本中，要么应该发出“合并冲突”信号。此时，您可以在提交之前手动解决冲突。
请参阅 http://svnbook。 red-bean.com/en/1.7/svn.tour.cycle.html#svn.tour.cycle.resolve。
Doing an SVN update should either gracefully merge the other developer's changes into the first developer's working copy, or it should signal a "merge conflict". At which point you resolve the conflicts manually, before committing.
See http://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html#svn.tour.cycle.resolve.
您在每个文件属性上设置需要锁定。这迫使每个开发人员在编辑文件之前锁定文件。
这通常不是您想要的工作方式，但如果您的开发过程需要它，那就去做吧。
You set requires-lock on each files properties. This forces each developer to lock the file before editing it.
It's normally not they way you wanna work but if you development process requires it then go for it.
只要您在更新之前将文件保存在工作目录中，那么您就不会遇到您所描述的问题。
我认为您应该能够通过执行以下操作将本地目录回滚到以前的版本：
然后保存您正在编辑的文件，然后执行以下操作：
然后应该合并更改或提示您本地目录中存在冲突。
一旦解决了冲突（如果有），您就可以提交回存储库。
As long as you save the files in your working directory before doing an update to it then you won't have the problem you are describing.
I would think you should be able to roll back your local directory to the previous version by doing a:
Then saving the file you are editing, then doing a:
which should then either merge in the changes or prompt you that there is a conflict in the local directory.
Once you resolve the conflict (if there is one) you can commit back to the repo.
只是合理工作流程：
Just rational workflow: