我的软件团队正试图将我们的源代码管理系统从Microsoft不再支持的Visual source Safe更新为Subversion（因为我们的姐妹网站已经使用了它）。我们有很多共享代码，在VSS中，这些代码可以通过内部链接直接完成。这些文件需要移动到共享文件夹中，以便多个项目使用。尽管可以使用外部代码来引入这些代码，但它们有一定的风险，并且不能自然地集成到SVN架构中（尽管我们仍然打算将它们用于第三方代码和其他不变的东西）。无论如何，我们提出了一个我在任何地方都没有看到描述的解决方案，但我们都认为这是有道理的，所以我想看看其他人怎么想，以及是否存在陷阱（还没有实际尝试过）。
所以我称之为"共享内部"文件夹，与外部文件夹形成对比。假设我的存储库根目录中有一个名为Common_Code的目录，其中包含给定语言（本例中为C++）的通用库文件。现在我创建了MyProject，带有trunk/branchs/tags，并希望将共享文件夹放在我的项目的子目录中。因此，我创建了一个普通的subversion分支，从Common_Code分支到MyProject/trunk/Common_Code。因此，不同的团队成员通过分支主干来处理MyProject。Bob的分支可能如下所示：MyProject/strants/Bob_Working，子文件夹将分支到MyProject/straints/Bob_Working/Common_Code。这实际上是共享文件夹分支的一个分支。
当Bob完成后，他合并回主干。这样做不会干扰任何其他项目，这些项目可能也在根共享文件夹之外创建了"内部分支"。我们最终发布了我们的产品，但发现我们对Common_Code进行了一些通用更改，这将有利于其他项目。因此，经过一些小组审查，我们同意将我们项目的Common_Code版本合并回最初使用的根版本。这将更新发布共享代码的需求与与与公司其他部门共享更改的需求脱钩。
这似乎是一种简单而灵活的本地共享代码的方式。我认为有两个可能的局限性。首先，它不能跨存储库工作，在这种情况下需要使用外部。其次，合并后不能删除第一个分支，所以我不认为会使用-reintegrate。我仍然不确定是否可以接受正常的合并，或者我们的Tortoise客户端是否支持它。
经过更多的研究和讨论，我们决定坚持使用外部共享代码的方法。我发布结论报告是为了让其他人能够从我们能够确定的理由中受益。如果人们认为这将有利于其他人，请投票，以便看到它。
我回顾了我们的姐妹网站关于外部的政策，然后试图提炼出这两种方法之间的主要根本区别。我最初没有意识到的一件事是，他们描述了一种更新外部文件的方法，这种方法可以在不需要在公共文件夹上有主干和分支的情况下完成——这对我来说是一个很大的负面影响，但它已经消失了。差异可以归结为：
Externals方法允许您根据需要固定到公用文件夹修订版，但如果您想更改公用代码，则需要取消固定，在本地更新到最新版本，添加自己的更改，然后提交回公用文件夹。换句话说，每个人都在公共区域的主干道上工作——但钉子让你在想要做出改变之前不会受到影响。它通过在项目特定代码和它使用的公共代码之间添加一定程度的分隔来保持公共代码的同步。
双分支允许您在本地隔离地更改公共代码，但需要记住稍后将其合并回公共主干中。从某种意义上说，它走的是另一条路——它使项目特定的和通用的代码始终保持同步和分支，但在项目版本的通用和共享的通用之间增加了一定程度的分离。
这种区别的一个实际结果是，对于外部代码，您必须首先（在提交时）合并公共代码，然后再合并到项目主干中。但其他项目则被搁置，因为它们与早期版本挂钩。另一方面，双分支允许您先合并到项目主干中，然后再合并公共代码（第二次合并）。尽管在这种情况下，你可以按任意顺序进行。
我们曾提出让项目选择其中一种方法的想法，但有人正确地指出了尽可能坚持统一政策的好处。根据我现在的了解，如果必须选择一个，我会选择externals方法，因为在我看来，共享代码应该在整个存储库中保持一致。通过赋予它与特定项目的独立性，它迫使人们考虑确保通用代码足够通用。如果有人真的想为项目使用定制它，那么他们应该制作所需文件的单独副本，并在项目目录中进行。毕竟，在这种情况下，没有合并回原始目录的意图，所以没有必要打开这扇门。