我正在使用subversion进行版本控制。
我经常看到提交相互覆盖的实例。在git中，这是有效的，因为如果您的本地仓库已过期，则无法推送。颠覆中是否有类似的机制？
e.g。
Bob使用svn update更新了他的工作副本。他继续在几天内对文件A进行一些更改。
同时，Alice更新了她的工作副本，并对文件A进行了一些小改动，然后在同一天提交。
大约一天后，Bob提交了他的更改 - 其中不包括Alice对文件A的更改 - 覆盖和删除Alice的更改。当Bob提交时，他没有得到任何警告，没有冲突或任何迹象表明他需要先更新，因为回购已经改变。
Bob没有故意触及Alice更改的任何代码行，但由于他的工作副本在提交时不包含Alice的代码，结果是repo只有Bob的更改，并且Alice有消失了。
尽管Bob和Alice都有一个流程，这意味着他们应该在提交之前使用svn更新，但似乎（对Bob来说）svn并没有强制执行此操作而且Bob经常忘记。
我们如何防止这种情况？
[编辑] 感谢所有到目前为止的人。看起来你们都在说同样的话 - 我所描述的不可能发生。不幸的是，我使用svn，使用不同客户端和不同版本的svn数年（开启和关闭）的经验完全如上所述。看起来我在svn中缺少一个基本的东西，它可以防止在你的工作副本不同步时提交代码 - 虽然这里有所有的答案，但我认为svn可以防止它发生太多次了。所以有些事情是棘手的 - 我需要找出什么 - 有没有人对所描述的感知效果如何发生有任何建议（没有Bob故意删除Alice的代码然后向世界撒谎）？
PS：我是鲍勃。
答案 0 :(得分：4)
尽管Bob和Alice都有一个流程，这意味着他们应该在提交之前使用svn更新，但是没有任何技术可以强制执行此操作并且Bob经常忘记。
那是因为 没有任何技术可以完全保护您免受不注意他们正在做的事情的用户。
与此同时，Alice更新了她的工作副本，并对文件A进行了少量更改，然后在同一天提交。
大约一天后，Bob提交了他的更改 - 其中不包括Alice对文件A的更改 - 覆盖并删除Alice的更改。
如果没有运行svn update，Bob无法提交，如果他更改了Alice更改的内容，则会触发Bob必须解决的冲突。如果Bob自己没有正确解决它，是的，Alice的工作可能会丢失 - 但这是一个“人”问题，而不是技术问题。没有软件可以阻止Bob不正确地管理代码冲突。
答案 1 :(得分：4)
[编辑]感谢所有到目前为止的人。看起来你们都在说同样的话 - 我所描述的不会发生。不幸的是，我使用svn，使用不同客户端和不同版本的svn数年（开启和关闭）的经验完全如上所述。看起来我在svn中缺少一个基本的东西，以防止在你的工作副本不同步时提交代码 - 它发生了太多次让我相信svn可以阻止尽管这里有所有的答案。所以有些事情是棘手的 - 我需要找出什么 - 有没有人对所描述的感知效果如何发生有任何建议（没有鲍勃故意删除爱丽丝的代码，然后向世界撒谎）？
鲍勃/ Hippyjim，
我偶尔会遇到这种情况，我的团队中的用户遇到同样的问题，并且他们发誓他们没有被该工具发出警告。我仍然试图找到它的底部，但我相当自信他们正在以某种方式做某事，导致他们在不知情的情况下覆盖变化。以下是我发现这种情况的两种情况：
1。）Bob检出修订版100. Alice提交更改，修订版101.Bob尝试提交更改并被迫更新，但现在有冲突。鲍勃被冲突所震撼，并犯了其中一个错误：
... 1.a。）在更新之前，Bob复制了他已更改文件的备份，现在将其复制回工作副本。
... 1.b。）Bob选择＆＃34;使用整个文件＆＃34;在合并工具中，在他的版本上，没有实际考虑冲突。
... 1.c。）Bob手动修改工作副本文件，并手动删除该工具放入文件的统一差异文本。
2。）Bob正在两个地方处理源代码。一个位置与SVN绑定，一个可能不是（可能是基于Web的，在另一台计算机上，或在另一个文件夹中） - 或者它可能是不同分支/存储库的工作副本。有时，更改是在OTHER位置进行的。鲍勃像一个好男孩一样更新他的主要工作副本。 Bob意识到他已经在其中一个来源中对文件A进行了更改。他将文件复制并粘贴到他的工作副本中并提交。
无论哪种方式，这些都是培训问题，并且是由不良做法引起的。
至于（1.）：不理解合并和冲突解决可能导致这些情况。
至于（2.）：复制和粘贴是一个坏主意，除非你在使用SCM时非常小心。系统不知道您是否复制并粘贴了旧更改，或者是否手动输入了所有旧更改。制作文件的副本或备份也会造成麻烦（复制文件和创建＆＃39; .bak＆＃39;版本是我看到的＃34;旧学校＆＃34;开发人员有时会这样做） - 并且不应该＆＃因为SCM系统不应该让你丢失你的代码，所以真的有必要。如果您未能使用工具提供的合并工具，则可以欺骗该工具以允许您覆盖旧的更改。
这些是我在没有经验的开发人员中看到的情景。即使是优秀的开发人员也有时会遇到复杂的冲突解决方案。
最后一个想法......你使用什么SVN客户端？我不知道有任何不会对过时的工作副本发出警告（就像其他评论者一样）。我在Windows上使用了命令行SVN，在Windows上使用了SlikSVN和TortoiseSVN。
答案 2 :(得分：1)
我仍然对你的情景感到困惑。
鲍勃用svn update更新他的工作副本。他继续在几天内对文件A进行一些更改。
Bob更新，我们将假设一份干净的工作副本，并对File＆＃34; A＆＃34;进行更改。了解。为了论证，让我们说Bob的工作副本是基于修订版＃100。
与此同时，Alice更新了她的工作副本，并对文件A进行了少量更改，然后在同一天提交。
好的，Alice更新了修订版100，并进行了更改。她承诺修改＃101。
大约一天后，Bob提交了他的更改 - 这些更改不包括Alice对文件A的更改 - 覆盖并删除Alice的更改。当鲍勃做出提交时，他没有得到任何警告，没有冲突或任何迹象表明他需要先更新，因为回购已经改变。
好的，你在这里失去了我。 Bob的工作副本基于修订版100.但是，此工作目录的最新版本将是修订版101.除非Bob首先更新到修订版101，否则Bob无法提交。
在你提交之前必须更新是一个很大的，笨重的线索棒，在kisser上攻击开发人员。这是一个警告，你的道路充满了危险：别人正在做同样的事情。谨防！小心！
此时，Bob应该做svn log来查看更改内容以及原因。也许Alice正在修复Bob正在处理的同一个bug。也许爱丽丝正在研究一个略有不同的bug。鲍勃本应该能够看到Alice在那时改变了文件A，甚至改变了她改变的行。
仍然，Bob需要进行更新，Bob会看到文件A被合并而不是简单地更新。这是一个迷失在太空机器人危险将罗宾逊类型的警告。
这很难被忽略，特别是如果Alice更改了Bob正在处理的一条线路。那会导致合并冲突。这是反应堆堆芯过热 - 爆炸是内在的。当然鲍勃可以忽略那个警告。他们在切尔诺贝利也这样做了。
鲍勃可以手动还原爱丽丝的台词。或者，如果需要合并，只需使用他的修订版来覆盖Alice的更改。这不是偶然的。
没有什么可以阻止Bob恢复变更。 Bob可以浏览整个Subversion日志并删除Alice的所有提交。没有版本控制系统不会阻止用户删除更改。如果更改不好，您想要还原它。
问题可能是Bob在文件A中进行了一些非常微妙的更改。也许文件A是Bob正在精心修改的图标或gif。鲍勃是一位艺术家。爱丽丝的改变只会导致鲍勃所做的事情出现问题。
如果是这种情况，Bob可以锁定文件A.在Subversion中，文件锁定通常是建议性的。但是，当Alice想要进行更改时，她会看到文件A被锁定，并且Bob已经锁定了它。鲍勃甚至可以发表锁定评论。
这可能是Alice的指示，她必须与Bob密切合作。然而，如果鲍勃决定去百慕大两个星期，爱丽丝可以窃取锁定并仍然进行更改。