如果有两个用户在同一个文件上工作,并且user A
在user B
之前提交,那么user A
的提交会在没有警告的情况下被覆盖。为什么svn允许覆盖以前的提交?
这是为什么,有什么办法来防止这种情况?
这只是发生在这里,我不得不通过修补user A
user B
的提交后所做的修改。
这似乎是危险的,不能告诉特定文件的基础尚未更新?
如果有两个用户在同一个文件上工作,并且user A
在user B
之前提交,那么user A
的提交会在没有警告的情况下被覆盖。为什么svn允许覆盖以前的提交?
这是为什么,有什么办法来防止这种情况?
这只是发生在这里,我不得不通过修补user A
user B
的提交后所做的修改。
这似乎是危险的,不能告诉特定文件的基础尚未更新?
SVN将不会仅仅覆盖userA
s提交,除非userB
明确要求。这不是偶然发生的事情。
现在userB
需要做一个SVN更新。有两种方法,现在这个可以去根据文件类型:
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
的提交方式,并让他们再次尝试。
您的文件是二进制文件还是ascii文件? – Stewart