我打算在这里建立一个规则，所有svn：externals引用应该来自另一个项目的标记，从不来自它的主干或来自它的任何分支。这是一个合理的规则还是你看到这种方法的问题/问题？我正在努力实现一个稳定的开发环境，我想知道这条规则是否会使开发变得更慢或更困难。
答案 0 :(得分：4)
您担心的是，带有“svn：externals”的项目可能会更改，而不会对该项目进行任何提交。这是一个问题，因为很难发现突破性的变化或回滚到一个好的版本。
所以是的，要求svn：外部引用是稳定的是一个很好的规则。只允许引用标签是实现这一目标的一种方法。另一种方法是使用-r语法将外部引脚固定到固定修订版。示例from the subversion book：
第三方/皮肤-r148 http://svn.example.com/skinproj
这也可以保护您免受标签变化的影响，这是一种比我更常见的不良做法。
话虽如此，稳定性与持续整合之间仍然存在着一种“强烈的权衡”。通常，您无论如何都需要在外部依赖项中进行更改和错误修复。在这种情况下，您希望CI服务器尽快通知依赖项中的某些更改会破坏您的项目，以便尽快修复问题。大多数持续集成服务器都支持检查外部。
由于这个原因，我认为可以将主干保留在主干跟踪你的依赖关系的主干HEAD（如果你有一个CI服务器）。在标记和创建稳定的维护分支时，只需将您的外部设备固定到固定版本。
答案 1 :(得分：2)
我认为这取决于您的软件开发实践的成熟程度。你有变更管理流程吗？自动构建和报告？等等。最安全的做法是链接到项目的标记构建（即lib，dll，jar等）。
如果外部项目的每周发布版本经常修复错误，那么它可能既有用也有阻碍。我发现如果没有良好的配置管理策略，链接到标签可以很容易地错过关键更新。而且，当你开始“升级”这种依赖时，可能会有很多小的变化，这些变化会增加很多工作。
在相对稳定的项目上，这是一个好主意。唯一的问题是并非所有IDE都清楚地表明源目录是外部引用。在这种情况下，开发人员很容易签入对该标记的更改。我记得，Subversion还没有实现“只读”，虽然我一直在使用旧版本。
答案 2 :(得分：2)
实际允许外部的决定？确保你出于正确的理由这样做。通常最好从原始地点结账，或者在多个地方检查依赖关系。我过去曾被外部参考资料烧毁过。如果你要分支，他们就会成为一个真正的问题，除非你在做“冻结”外部时。
但是要回答你的问题，有一个特定的位置可以放置和引用所有外部结构，这很有意义。这意味着您可以控制该位置的内容，并且人们知道当他们在那里放置某些东西时，它将被用作外部，因此依赖于许多项目。
答案 3 :(得分：2)
这取决于你认为后备箱的稳定性。
但是，对于开发人员来说，将外部组件的工作副本切换到主干是很好的。在开发分支中指向trunk也很好。在项目的第一个稳定版本发布之前指向trunk可能没问题。
我个人的看法是非常小心地对待行李箱，因为它对我有特殊的意义 - 这是项目的完整历史。根据定义，任何被释放的东西都必须通过主干。如果您可以在没有针对更改记录的修订版本的情况下更改主干（实际上，如果您指向外部主干，则会发生这种情况），您已经失去了对何时发布该修订版本以及将该修订版本合并到项目中的控制权
当您从主干分支时，记住要更改对特定修订的所有引用可以是试用版。 Hudson可以通过标记支持使事情变得更加明显，但是其他方面也没什么帮助。
指向行李箱也会导致“untouchable library”问题。
对于CI而言，没有理由不能对所有组件以及最终的集成项目执行CI。通过选择在最新库中合并的时间，您可以选择何时进行集成工作。
但是，有一种机制可以说“你的项目使用的是过时的库，最新的版本是X”，这样会很好。目前这是不可能的。
此外，如果您有嵌套的外部，将基础库中的更改推送到5层引用，直到它到达主项目是一件痛苦的事。