考虑一下情况。我想将一个更改的文件提交给SVN，看看其他人在我签出后提交了同一个文件，所以我必须“更新”并合并更改。虽然我这样做有人再次提交相同的文件，所以当我尝试提交合并文件时，我必须再次更新。
现在，如果其他用户经常提交，看起来我将永远无法提交我的更改。真的是这样吗？在真实的开发环境中如何解决这个问题？
答案 0 :(得分：24)
这通常被视为不是技术问题，而是“人”问题。它通常表示团队之间的沟通失败，如果您发现自己处于这种情况，您应该与您的开发人员讨论如何更好地划分您的工作。
在大多数情况下，正如您所发现的那样，开发人员同时在相同的代码区域中工作而没有良好的协调是不切实际的。
如果您确实以这样的速度发生这种情况，甚至无法提交更改，那么您已经超越了问题，听起来像是拒绝服务攻击：）。
答案 1 :(得分：9)
首先让我们假设它不是一个游戏，或者在你出去愤怒的时候故意让你生气并偷走你漂亮的椅子...... 但需要。 ; - ）
如果发生这种情况，该文件很难合并（大）并且经常更新（也会变大）。
此文件承担太多责任，应该逻辑拆分。
例如，对于整个应用程序，我们有一个这样的唯一属性文件。它甚至崩溃了Eclipse来比较文件的两个版本！ :-)所以一些开发人员不会比较和合并它，但提交覆盖其他人的提交！我们拆分文件，每个模块一个属性文件，问题就消失了。
通常还有其他与此相关的问题，例如开发人员在大文件中没时间找到他们想要的东西。拆分解决方案解决了所有这些问题。
作为临时解决方案，您可以与人员同步，以便他们为您提供合并和提交的打开窗口。但问题通常会一直持续到团队明确解决之后。 ; - ）
答案 2 :(得分：8)
你能不能锁定文件？
来自svn书http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html
svn lock banana.jpg -m "Editing file for tomorrow's release."
答案 3 :(得分：5)
您可以尝试创建自己的分支并针对该分支进行开发。完成功能后，将分支合并到头部。这样，您可以推迟合并活动，直到您的工作完成。它并没有解决你的问题 - 你仍然需要进行合并 - 但它确实推迟了它，让你继续你的工作。也许如果开发团队中的每个人都遵循这种做法 - 或者只针对在相同领域工作的人员使用分支机构 - 那么在主要开发分支中，文件的更改问题就会更少。
答案 4 :(得分：5)
您正在查看问题，好像其他用户的情况与您的情况有所不同。事实并非如此：问题不仅会影响您自己，也会影响所有其他用户。
这并不是说那些其他用户是精英群体的成员，只会导致问题，但从未体验过。
换句话说：
如果其他用户经常提交以至于您永远无法提交更改，因为您必须不断更新，那么其他用户也将无法提交他们的更改，因为他们将必须不断更新自己。这将减慢所有提交的速度，在任何特定时间，某人将能够提交他的更改而无需更新，包括您自己。
tl; dr：问题会自行解决。
答案 5 :(得分：3)
虽然开发人员在同一个文件上工作是相当普遍的，但几乎不需要连续两次执行更新，因为人们在你有机会完成合并之前就会提交。
如果是这样的话，并且你有5个人在同一个文件上工作（本身就很疯狂），每5分钟做一次微提交，我会说你有其他问题你应该担心和需要重新构建你的代码，并给他们（你的同行）一个正确的'bollocking'。
答案 6 :(得分：3)
OrbMan说这是一个人的问题是正确的，你需要找到一个更好的工作方式。但是，它也可能指向潜在的架构问题。拥有一个需要经常被许多不同开发人员更改的文件是一个坏主意。
答案 7 :(得分：2)
虽然我完全同意@OrbMan，但我建议使用“Get Lock”命令，但仅作为最后的手段。
答案 8 :(得分：2)
虽然我同意OrbMan - 如果文件更新速度太快以至于您无法进行更改，那么潜在的问题就是开发人员之间的沟通 - 有技术解决方案。
SVN确实支持锁定文件的概念。您可以尝试锁定文件，以便在您合并更改时其他人无法提交。提交更改时，解锁文件，一切正常。
也就是说，SVN确实允许人们打破锁定。例如，如果有人锁定文件而忘记在去度假前解锁它。所以，即使你确实锁定它，有人可能会在完成合并之前打破锁并提交代码。但是，如果有人打破了命名用户锁定并提交而没有先检查它们，那可能是缺乏开发人员之间沟通的更糟糕的例子，而且更多的是“人”问题。
答案 9 :(得分：1)
如果文件经常被评论，也许它不应该受源代码控制？我对此的测试是：“我是否可以随时对每个修订版（即标签）进行有意义的英文描述？” - 如果没有，可能不应该控制它。
答案 10 :(得分：1)
这不是解决方案，而是解决方法：使用git-svn作为Subversion存储库的本地客户端。