在Subversion的混合版本工作副本中查找错误

Question

我工作的项目最近已经从一个可怕的过时版本控制系统切换到了Subversion。我觉得我几年前对Subversion有相当好的理解，但是一旦我了解了Mercurial，我就很快忘记了Subversion。

我的问题是针对那些在Subversion的同一分支上与大量（15+）开发者合作的人。

让我们假设您检出存储库的修订版本N。你做了一些改变，然后提交。与此同时，其他开发人员对其他文件进行了更改。您听说另一个开发人员对子系统X所做的更改，并决定立即需要它们。你不想更新整个工作副本，因为它会引入各种各样的东西，然后你将不得不做一个冗长的编译（C++项目）。我看到的风险是，开发人员仅更新子系统X，但未意识到新代码依赖于子系统Y中的最近更改。代码编译，但在运行时崩溃。

你如何处理这个问题？

• 开发者是否报告他们认为可能是错误（即使它不是bug）？
• 您是否需要开发人员在报告错误之前更新其整个工作副本？这不会阻止错误报告吗？
• 你是否通过一些我没有想到的机制来防止这种情况发生？

Answer 1

由于您提交了所有正在进行的工作，因此您没有理由不更新整个最新版本的副本。冗长的编译是大型项目价格的一部分。编译时间几乎总是少于尝试确定是否有bug的时间，或者是否因为没有检查完所有内容而存在一些模糊的不兼容性。

该项目已将编译分发到组中的所有工作站。由于我们有大约15台计算机用于这项任务，这意味着通常需要6个小时左右的时间才能完成大约25分钟。

Answer 2

追踪依赖关系的责任是引入它的develloper。 在这种情况下，develloper X应确保更改与其他子系统的当前版本一起工作。或者至少记录它与哪些版本协同工作。

我见过的帮助解决方案处理这个问题的方法是。

1. 在构建系统中包含依赖检查。许多开源项目都是在.configure脚本中完成的。
2. 配置版本控制系统为您处理。我不知道在颠覆中这样做。

这显然不是长时间的编译时间，但它有助于避免不必要的重建。 复杂的依赖图也是可疑设计的一个指标。重构代码以减少子系统之间的耦合可能是个好主意。