我即将在这里建立在工作的规则，所有的svn：外部对象的引用应该是来自其他项目的标记的一个，从来没有从它的树干或任何其分支机构。 这是一个合理的规则或你看到这种方法的问题/问题？ 我想实现一个稳定的发展环境，我不知道这个规则将使发展较慢或更加困难。
Answer 1:
你关注的是，与项目“的svn：外部组件”，可以变更，恕不另行提交到该项目。 这是一个问题，因为它很难发现重大更改或回滚到一个很好的版本。
所以，是的，要求的svn：外部引用稳定是一个好的原则。 只允许引用标记是实现这一目标的方法之一。 另一种方法是使用-r语法到外部引脚到固定的修订。 例如从颠覆书 ：
第三方/皮-r148 http://svn.example.com/skinproj
这也将保护您免受在标签的变化，一个不好的做法，这是更常见的比我喜欢。
话虽这么说，还有稳定性和持续集成之间的权衡 。 通常你需要在外部依赖的变化和错误修正反正。 在这种情况下，要被你的CI服务器尽可能快地在依赖一些变化打破了你的项目通知，使问题能够尽快解决。 大多数持续集成服务器都有检查的外部支持。
为此，我认为这是确定以保持树干的外部跟踪你依赖的树干HEAD（如果你有一个CI服务器）。 只是标记和创造稳定的维护分支时，当你的脚的外部固定修订。
Answer 2:
我认为它归结为你的软件开发实践是如何成熟的。 你有变更管理流程？ 自动的构建和报告？ 等做最安全的做法是链接到该项目的标记，构建（即LIB的，DLL的，罐子的，等等）。
如果外部项目有每周发布的频繁bug修复，也可能是两者有帮助和阻。 我发现，没有一个良好的配置管理政策，结合标签可以很容易错过重要更新。 而且，你的时间避开“升级”这种依赖，可能会有很多，加起来大量的工作小的变化。
在相对稳定的项目，这是一个好主意。 唯一的问题是，并非所有的IDE的说清楚，源目录是外部refernce。 在这种情况下，它变得非常容易为开发商签入更改该标签。 从我记得，颠覆没有执行“只读”，但是，虽然我一直在使用的旧版本。
Answer 3:
并决定实际允许的外部？ 确保你这样做是正确的原因。 它往往是更好地简单地从原来的地方，或签，签在多个地方的依赖关系。 我已经在过去的外部引用烧毁。 如果你要跳转他们成为一个真正的问题，除非你当你做“冻结”的外部。
但是，为了回答你的问题，这让很多的意义有一个特定的位置，所有的外部被放置和参考。 这意味着，你可以控制该位置的内容和人都知道，当他们把东西有那么它将被用作外部，因此受到了很多的项目依赖。
Answer 4:
这取决于你考虑如何稳定汽车的后备箱里。
- 如果你的箱子的东西，总是准备好释放，那么你真的不希望你的外部指向主干。
- 如果您有只在从主干的修订合并改变发布分支，那么你真的不希望你的外部指向主干。
- 如果由于某种原因，你想在树干修订，说：“我现在正在使用的该版本外的”，因而采取的所有更改到您的项目代码控制，那么你不希望你的外部指向主干。
然而，它的罚款用于开发自己的外部的工作副本切换到躯干。 这也是罚款指向一个发展分支内主干。 这可能是确定指向一个项目的第一个稳定版本到主干。
我个人的看法是非常小心地对待主干，因为它有特殊的意义，我 - 这是该项目的完整历史。 凡是得到释放必须通过主干，由定义。 如果你可以改变主干，而无需对记录的变化进行修订（这是如果指向外部干路有效地发生了什么），你当你纳入该修订到你的项目失去了控制，当你释放了修订，并。
记住，当你从主干分支切换到特定修订所有的引用可以试用。 哈德森可以使事情有它的标签支持更为明显，但没有其他人的帮助。
他指着后备箱也可导致“ 贱民库 ”的问题。
当涉及到CI，没有理由为什么你不能做所有的组件，以及最终的综合项目CI。 通过选择时，在最新的库合并，你选择，当你想要做的整合工作。
然而，这将是很好有一些机制，说：“你的项目使用过时的库，最新的版本是X”。 这是不可能的时刻。
此外，如果您已经通过5层参考的嵌套的外部，推动从基础库的变化，直到它到达主要的项目是一种痛苦。
文章来源: Subversion - where should the svn:externals come from?
