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