（注意：这个问题不是特定于Subversion的 - 我只是在这里使用它作为例子。）
我知道“svn update”命令（或其他类似命令在其他系统中）将使用存储库中的文件更改来更新工作副本。我也知道在源代码控制中最好的做法是定期执行svn更新，以确保在最终提交（签入）这些更改之前已经获得了最新的更改集。
这种最佳实践的另一种方法（可能是最糟糕的做法：>）只能在提交（签入）时间管理潜在冲突，而不是在编辑文件期间定期管理。
看起来最好的做法是采用“悲观”的方法尽早和经常地管理冲突，而不是仅仅在提交时管理冲突并在以后管理所有累积冲突的“乐观”方法。
我是否正确地说明了最佳实践与替代方案的意图？
我个人每天在开始工作时更新我的工作副本。我发现早期发现冲突并以这种方式快速解决。
如上所述，我的建议类似：
第二点也非常重要：一旦“某些东西”起作用，就必须承诺，文献中说“不要失明”，即不要在你的硬盘上继续开发一个月，直到它是完美的（它永远不会是:-)）
这是Continuous Integration背后的基本思想（很多关于Martin Fowler网站的资料和非常明确的解释）。
太过分了：
在我以前的工作中，产品部门的一些人会拒绝每天更新（甚至更少一天），因为他们说：“如果我更新，行李箱会坏掉，我会放松一天”。他们是对的！这是不可接受的！这就是为什么强调只有工作代码应该被提交（或推送给DVCS人员）非常重要的原因：帮助强制执行这个我设置每日构建，这将在每次提交时开始（使用免费软件buildbot工具，但几十个类似工具存在）。通过on-commit构建和测试，可以更容易地确定主干没有损坏;无论何时构建或（简单）测试失败，已经（刚）提交的人都会收到一封电子邮件，他们必须立即解决问题或恢复。并且网络摘要（在buildbot词汇表中称为瀑布）在这里供所有人查看。总而言之，在开发人员之间建立和相互信任真的是一种心态，但是一旦你达到这一点，相信我，你永远不会想要回来：开发更快但协调，人们我们很乐意为同一个代码做出贡献，而不是单独在他们的工作站上工作一个月！值得尝试走这条道路（恕我直言）。
是的，悲观是好的。早些时候，更小，更不全面的变化更容易
当然，这取决于相同代码中有多少其他开发人员以及他们使用您正在处理的模块的可能性。 （例如，我目前是唯一一个在我的项目中工作的人。我不像其他人在那里那样频繁刷新。）
正确的是，随着分布式版本控制方法的兴起，越来越多的人倾向于“变暗”，就像有人会说的那样，为了自己的东西而开始工作并担心以后合并它。
包括我自己在内的许多人会说，这会导致更多难以解决的冲突，因为您实际上是在不同的分支机构中运营，因此朝不同的方向发展。
定期更新确保您不会远离其他人的路径，但许多其他人认为这会破坏分布式版本控制的灵活性。
另一种方法是在你自己的分支机构工作，而不是主干。这样，当您的功能/错误修复/无论何时完成时，唯一的合并就完成了。没有其他人会在你的分支上作出承诺，所以在你完成之前你是安全的。
有一些中间立场 - 您可以将更改保留在分支中，与正在进行的主干更改分开。这在git中非常容易，而且在颠覆中不太容易（我会说）。这可以让你做的是定期从trunk中提取更改，而不会自动“冒险”你的本地更改被与trunk提交冲突搞砸了。我认为，这就是为什么你不想提取更新的核心 - 也就是说，因为你还没有为他们做好准备。你会看到发生了变化，这是一件非常好的事情。在单独的分支上进行更改意味着您可以尝试合并上游更改，但如果它们不匹配，您可以中止该合并并继续在代码上工作一段时间，直到您准备好真正花费精力解决冲突。
绝对正确的是，您重新调整代码以使其与主干兼容（通过svn更新或合并更改），解决冲突就越容易。等到你准备好发现变化以发现一切都已经从你身下移动是非常可怕的 - 你将花费更多的时间来挖掘日志，试图找出变化是什么以及如何正确应用他们对你已经想过的代码很好，然后你需要用新的更改重新测试你的代码！如果你一直在合并，那么你已经测试了这个版本。
=>多年的无故障SCM使用。
听起来很对。当然，如果你经常提交而不是等到你有大量的改变，那么这两种方法都是相同的。
我认为这完全取决于代码中的依赖项数量以及同时处理相同代码的开发人员数量。如果几乎没有开发人员使用相同的代码，那么您可以在不与存储库中的代码“合并”的情况下使用更长的时间。我个人喜欢等到我的开发结束，只要它不会花费我几个星期才完成。如果需要几周的时间才能完成，您应该将功能分成更小的部分，并使用更加增量的方法，这样您就可以检查新代码并更频繁地合并。