为什么svn允许覆盖以前的提交?

时间:2017-06-09 20:43:23

标签: svn commit base revision

如果有两个用户在同一个文件上工作,user Auser B之前提交,则user A的提交会在没有警告的情况下被覆盖。

为什么会这样,有没有办法阻止这种情况?

这只是发生在这里,我必须通过修补user Auser B提交之后所做的更改来修复它。

这似乎很危险,不能告诉特定文件的基础没有更新吗?

1 个答案:

答案 0 :(得分:2)

除非userA明确要求,否则SVN不会覆盖userB次提交。这不是偶然发生的事情。

userB尝试提交其文件时,SVN将显示错误 enter image description here

现在userB需要进行SVN更新。现在有两种方法,具体取决于文件类型:

ASCII

SVN真正用于处理ascii(文本)文件。如果您执行SVN更新,它会将userA中的更改“合并”到userB文件中。这意味着userA更改的所有行都将在userB的工作副本中更改。 userB应该真正检查合并,以确保更改不会破坏userB尝试执行的操作。如果两个用户都更改了相同的行,则会标记冲突。 userB需要审核冲突,找出userA尝试完成的内容,然后手动决定如何保留两个用户的更改。

二进制

SVN并非真正用于合并二进制文件。当合并适用时,您需要依赖为特定二进制文件定制的工具。当userB执行更新时,会发生冲突,userB将无法查看差异并合并文件。如果没有可用于该特定二进制类型的合并工具,userB将需要接受userA的版本,然后使用生成该二进制文件的任何工具重新对二进制文件进行更改。

userB可以通过保存他/她的工作副本的副本,执行svn update,然后恢复副本和提交来绕过此工作流程。这将恢复所有userA的更改。特别是在这种ASCII情况下,这被称为冲洗移动。在二进制的情况下,两个用户应该真正沟通并决定两者中的哪一个需要重做他们的工作。

在SVN中使用二进制文件时,这可能会成为一个大问题。解决方案是经常提交或使用acquire lock功能。另外,请务必在处理文件之前立即svn update,并在完成更改后立即svn commit

如果userB仅通过拒绝合并来摧毁了大量工作,那么您可以随时重新userB提交,并让他们再试一次。