SVN和多个项目之间共享的代码

我在SVN有多个项目。这些项目中的每一个都位于自己的主干中，并为发布而分支

每个项目都使用一个共享代码。问题是处理代码的最佳方式是什么

让我给出几个场景以及与之相关的问题

a） 将共享代码放在单独的主干（或存储库）中，并使用svn:external

在这种情况下，如果我们将一些项目分支，将有两个问题：

• 在主干中对共享代码所做的任何修改都将传播到分支，因为svn:external将接收更改
• 在这种情况下，如果我们需要在某个时刻返回并准确地构建为发布而构建的代码，我们将很难获得准确的代码，因为snv:external将再次获取共享代码的最新副本，而不是在项目分支时获取的代码

据我所知，有一个解决办法。一旦我们分支，我们就可以修改svn:external以获取共享代码的精确版本。然而，还有两个陷阱：

• 每次分支时都要记住这样做。（我讨厌这样的事情，很容易忘记）
• 如果需要对分支/发布的项目进行热修复，则不能修改共享代码

b） 另一种解决方案是在项目分支时分支共享代码，并将外部更改为指向共享代码的带括号副本

• 同样，问题之一是手动步骤，很容易忘记
• 另一个问题是合并问题。当您尝试将项目中的更改合并到主干时，SVN将跳过外部。所以，开发人员需要再次记住手动合并共享代码

---

我遗漏了什么吗？有什么合理的方法来处理这个问题吗

我个人保留一个单独的存储库，然后使用[svn:externals]属性

SVN Externals允许您在运行SVN更新时链接到其他存储库（即使是您未运行的存储库，例如smarty subversion repo），您的项目和外部repo都将被更新

使用SVN externals，您还可以使用

http://path-to-project.com/svn/thing -r1234

用于发布和其他需要保持静态的内容

---

IMHO的最佳实践是始终指定一个修订，然后在对共享库进行更改时更新修订号，以便跟踪更新此数据的原因。在标记或分支主项目时，还可以保持一切正常。

您有两个正确答案，但有两组缺点。
以下是我的建议

将共享代码放入另一个存储库， 用发布版本标记代码 在主干目录中创建一个指向标记的svn externals

更改库时，请重新标记库并更新主干应用程序。 获取分支时，分支仍将指向库的正确标记版本

---

或者尝试构建一个单独的库版本，并将库引用为jar或lib/so。

我建议处理共享代码（尤其是Java和.NET或C/C++库）时使用两组存储库：一组用于源代码，另一组用于对发布的图像进行版本控制。当您对“common”项目进行更改时，您将源代码更改提交到源代码树，然后构建它，然后通过在发布树上将其提交为新版本来发布二进制文件。使用“common”项目的项目随后使用svn:externals属性引入已发布的二进制文件。不存在修改共享代码的本地映像的诱惑。如果有人想要修改“公共”代码，那么他们可以通过该项目的正常开发实践来完成

---

有关更多详细信息，请参见类似的问题。

我们使用如下的单一存储库结构：

/trunk/project1
/trunk/classlibrary (shared code)
/trunk/project2

在C#（可能不是您选择的语言）中，project1和project2包含对类库的引用。当我们构建时（这是编译后的.NET模型的一大优势），会发现正在构建的项目和类库之间的任何不一致。这些不一致在提交更改之前得到解决。使用基于服务器的构建工具（我们使用CruiseControl.NET），我们可以同时构建所有项目，这将告诉我们任何问题

除非您的project1和project2需要引用一个特定版本的类库（我们避免使用，试图使project1和project2始终使用最新版本的类库），否则这项工作非常顺利

---

我倾向于避免为相关应用程序创建单独的存储库。由于上面示例中的class_库将所有这些东西联系在一起，所以在单独的版本中维护它没有什么好处或逻辑，因为它在项目级别被分离的真正原因是它是共享代码。共享代码的生产应用程序这样做是有原因的——它们应该使用相同版本的共享代码，这意味着它们应该是同一个源代码管理分支的一部分。

我们使用一个类似于CWT的系统：共享代码本身往往是独立的项目，因此在存储库中单独存在在使用外部项目（上游项目）的项目中，我们包括用于共享/下游项目的编译/打包二进制文件

这样上游项目就不会受到下游项目意外变化的影响

我们已经编写了一些脚本，以便在必要时使用这些二进制文件的更新版本自动更新主要的上游项目（否则，将包复制到适当的项目中是一个手动过程，但这并不是什么大问题）

到目前为止，我们在马德内斯方法中看到的缺点是，下游项目正在经历非常激烈的竞争