0

我的 SW 小组正在尝试将我们的源代码控制系统从 Microsoft 不再支持的 Visual Source Safe 更新到 Subversion（因为我们的姊妹站点已经在使用它）。我们有很多共享代码，在 VSS 中可以通过内部链接直接完成。这些将需要移动到共享文件夹中以供多个项目使用。尽管可以使用外部来引入这些，但它们有一定的风险，并且不能自然地集成到 SVN 架构中（尽管我们仍然打算将它们用于第三方代码和其他不会改变的东西）。无论如何，我们提出了一个我在任何地方都没有看到过的解决方案，但我们都认为这是有道理的，所以我想看看其他人的想法以及是否存在陷阱（实际上还没有实际尝试过）。

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

鲍勃完成后，他合并回树干。这将继续进行，而不会干扰任何其他可能也从根共享文件夹创建“内部分支”的项目。我们最终发布了我们的产品，但发现我们对 Common_Code 进行了一些通用更改，这将有利于其他项目。因此，经过一些小组审查后，我们同意将我们项目的 Common_Code 版本合并回最初使用的根版本。这将更新共享代码的需要与与公司其他人员共享更改的需要分离。

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

4

1 回答 1

0

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

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

Externals 方法允许您在需要时挂钩到公共文件夹修订，但如果您想更改公共代码，则需要取消挂钩，本地更新到最新版本，添加您自己的更改，然后提交回公共文件夹。换句话说，每个人都在公共区域的后备箱上工作——但钉子让你不会受到影响，直到你想做出改变。它通过在项目特定代码和它使用的通用代码之间添加一定程度的分离来保持通用同步。

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

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

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

于 2016-04-21T17:56:45.540 回答