Svn Subversion-共享公共文件夹而不使用外部文件

我的软件团队正在尝试将我们的源代码控制系统从Visual source Safe（微软不再支持）升级到Subversion（因为我们的姐妹站点已经使用它）。我们有很多共享代码，在VSS中可以通过内部链接直接完成。这些文件需要移动到共享文件夹中，以便多个项目使用。尽管可以使用external来引入这些功能，但它们有一定的风险，并且不能自然地集成到SVN体系结构中（尽管我们仍然打算将它们用于第三方代码和其他不变的东西）。不管怎么说，我们提出了一个解决方案，我在任何地方都没有看到描述，但我们都认为这是有意义的，所以我想看看其他人的想法，如果有陷阱（还没有实际试用过）

所以我称之为“共享内部”文件夹，与外部文件夹形成对比。假设我的存储库根目录中有一个名为Common_Code的目录，其中包含给定语言的通用库文件（本例中为C++）。现在，我创建了带有trunk/branchs/tags的MyProject，并希望将共享文件夹放在项目的子目录中。因此，我创建了一个普通的subversion分支，它从Common_代码分支到MyProject/trunk/Common_代码。 因此，不同的团队成员通过从主干分支来处理MyProject。Bob的分支可能如下所示：MyProject/Branchs/Bob_Working，子文件夹将分支到MyProject/Branchs/Bob_Working/Common_代码。这实际上是共享文件夹分支的一个分支

鲍勃做完后，他又回到车尾箱。这将继续进行，而不会干扰可能已在根共享文件夹外创建“内部分支”的任何其他项目。我们最终发布了我们的产品，但发现我们对公共_代码进行了一些通用更改，这将有利于其他项目。因此，在一些小组审查之后，我们同意将我们项目的Common_代码版本合并回最初采用的根版本。这使得更新发布版共享代码的需求与与与公司其他部门共享更改的需求脱钩

---

这似乎是一种简单而灵活的本地共享代码的方式。我看到两个可能的限制。首先，它不能跨存储库工作，在这种情况下需要使用外部。第二，合并后不能删除第一个分支，所以我不认为会使用-reintegrate。我仍然不确定仅仅一个普通的合并是否可以接受，或者我们的乌龟客户是否支持它。

经过更多的研究和讨论，我们决定坚持使用外部共享代码的方法。我将发布结论报告，以便其他人能够从我们能够确定的理由中受益。如果人们认为这对其他人有好处，请投票表决，以便大家看到

我回去回顾了我们的姐妹网站关于外部的政策，然后试图提炼出这两种方法之间的主要基本区别。我最初没有意识到的一件事是，它们描述了一种更新外部文件的方法，这种方法无需在公共文件夹上设置主干和分支即可完成，这对我来说是一个很大的负面影响，但后来就消失了。这些差异可以归结为：

Externals方法允许您根据需要绑定到公共文件夹修订版，但如果您想要更改公共代码，则需要取消绑定，在本地更新到最新版本，添加您自己的更改，并提交回公共文件夹。换言之，每个人都在公共区域的行李箱外工作——但在您希望做出改变之前，挂钩允许您不受影响。它通过在特定于项目的代码和它使用的公共代码之间添加一个分离级别来保持公共代码的同步

双分支允许您单独在本地对公共代码进行更改，但需要记住稍后将其合并回公共主干。从某种意义上讲，它是另一种方式——它使特定于项目的代码和公共代码始终在任何时间和分支上保持同步，但在公共和共享公共的项目版本之间增加了一定程度的分离

这种区别的一个实际结果是，对于外部，您必须首先合并公共代码（在提交时），然后再合并到项目主干中。但其他项目则被搁置，因为它们与早期版本挂钩。 另一方面，双分支允许您首先合并到项目主干中，然后再合并公共代码（第二次合并）。尽管在这种情况下，你可以按任意顺序做

---

我们提出了让项目选择其中一种方法的想法，但有人正确地指出了尽可能坚持统一政策的好处。如果我必须选择一个，根据我现在所知道的，我会选择externals方法，因为在我看来，共享代码应该在整个存储库中保持一致。通过赋予它与特定项目的独立性，它强制人们考虑确保公共代码保持足够的通用性，以供使用。如果有人真的想为项目使用定制它，那么他们应该为所需的文件制作一个单独的副本，并在项目目录中执行。毕竟，在这种情况下，没有人打算合并回原始目录，因此无需打开该门。

不要重新发明轮子！！！SVN外部是共享代码的自然方式（tm），它们自然地集成到SVN体系结构中。有了“工作流程”，您将非常头疼如何将更改从副本的副本合并回原始位置，当然。只需阅读更多关于外部的PEG修订（并且忘记不PEG ed）和外部的共同点是这个方案中共享内部几乎不可避免的分歧，直到它们不再在项目之间“共享”，这是你想要避免的？或者你还好吗