在版本控制中开发和使用通用库的最佳实践？答案

【问题标题】：Best practices for developing and using common libraries in version control?在版本控制中开发和使用通用库的最佳实践？
【发布时间】：2009-09-01 13:47:01
【问题描述】：

我一直想知道在两个或多个项目中使用的积极开发的公共库应该如何存储在版本控制中。我想它的处理方式与第三方库不同，因为内部库更有可能获得热修复，这些修复应该分发给版本控制中的许多项目。

是否应该将其二进制文件在更新时导入到使用它的项目中（很像第三方库），还是应该将其源代码与项目一起检出？是否可以引用 Subversion 或其他版本控制系统中的其他版本控制路径？

我现在正在一个项目中工作，该项目具有在 Subversion 其他地方（并在许多项目中使用）的公共库，因此在该项目中对它们所做的任何更改都不会反映在它们的“真实”中存储库。我将建议对此进行一些更改，但我想对处理这些公共库的最佳做法有一些想法。

【问题讨论】：

我很好奇为什么这是社区维基。我相信会有很多答案，但有一个对你有用并且会被接受，或者有人会发布一个链接，指向一组简单的指导方针，并且会被接受。
我通常将接近主观的问题标记为社区 wiki。可能有十种同样好的方法可以做到这一点。已定义的编程问题有明确的解决方案，我认为它们是正确的问题。
@Blixt，可以说，几乎所有“最佳实践”的讨论都是主观的。在不可重复的实验中衡量方法成功与否的能力很差。所以最后，它几乎总是转移到某些人认为最好的。
@CPerkins：是的，这就是为什么我希望它成为一个社区 wiki，因为它是人们经验和建议的集合，而不是明确答案的列表。尽管总体上应该避免主观性，但在这些情况下，几乎不可能避免，这就是我们拥有社区 wiki 的目的。 =)

标签： svn version-control

【解决方案1】：

正如其他人已经提到的，SVN's externals 是实现此目的的好方法。通过它们，您可以引用存储库的其他部分（或其他存储库，FTM）。一个项目可以引用其他（库）项目或某个分支或标签的头部。后两者有助于稳定性，前一个用于始终与库保持同步。

我已经看到了使用 CVS（这里没有外部，所以它是必须执行的签入脚本）和 SVN 的各种方案。在我现在工作的公司中，我们有不同的顶级文件夹用于项目和共享库。项目可以引用库。在项目的主干上，这些外部引用通常指向库的头部，在标签和分支上，项目引用库的标签（或者，有时是分支）。

【讨论】：

对于 Git，它将是 git submodule
我已经开始分解一般项目并使用svn:externals 引用它们，效果很好！
@Blixt：太好了。请注意，AFAIK，诸如签入之类的命令不会递归到通过外部引用签出的文件夹中。至少我上次看时他们没有。

【解决方案2】：

如果使用 Subversion，我会使用 svn:externals，它允许您创建一个 Subversion 存储库到另一个的依赖关系。

【讨论】：

【解决方案3】：

Subversion 确实允许您通过使用 svn:externals 属性来引用其他路径。

也就是说，您通常希望对项目状态进行更多控制，而不仅仅是“获取共享库头中的任何内容”。在这种情况下，我建议将编译后的库二进制文件提交到使用它的每个其他项目中。这样，您就可以控制将库部署到其每个客户端。

【讨论】：

【解决方案4】：

是的。

尽早并经常将可重复使用的“子库”分成单独的项目。

看看开源实践：大多数事情都是拼凑在一起的许多小项目。

创建许多小项目。

避免签入二进制文件。同样，遵循开源实践。在 subversion 中保留源代码。

构建二进制文件并将它们放在与源代码分开的“项目共享”目录中。

【讨论】：

【解决方案5】：

我们将来自 SVN 中公共库的代码保存在他们自己的项目文件夹中。我们还将二进制文件提交到另一个名为 Dependencies 的“项目”文件夹。我们使用 svn:externals 将所需的引用引入项目。

【讨论】：

【解决方案6】：

处理这个问题的正确工具是Maven。最初是为 Java 开发的，它可以用于任何现有的编程语言。

Maven 在所有模块所在的计算机上创建一个存储库。您还可以创建一个公共模块存储库，允许其他人从那里下载模块。

每个模块都有一个自动解析（读取下载）的依赖项列表。在项目的构建阶段，一个适合您的编程语言的插件会将所有依赖项放在特定的位置，以使源代码可以看到它们。

Maven 是一个很棒的多功能工具，但它很难掌握，仅此而已。

【讨论】：

+1，虽然我怀疑这实际上是否可以用于其他语言。如果可以的话，是否存在适用于 perl、python、ruby、php、c# 等的 maven 兼容存储库？

【解决方案7】：

我什至不明白这个问题。如果 foo 依赖于 libbar，为什么要将 libbar 的源代码保留在 foo 的 VCS 中？如果适合该语言，您可以链接到 libbar 或导入 bar 模块。为什么要混淆项目的源代码树？我的“你好，世界！”项目依赖于 libc。我的“你好，多莉！”也是如此。项目。这两个项目都没有将 libc 源代码保留在其代码库中。这样做将是疯狂的。为什么在这方面对待内部库与第 3 方库有任何不同？简而言之，最佳做法是：不要这样做。如果您的库有需要传播到您的项目的修补程序，则使用动态链接。

【讨论】：

是的，我想你误解了这个问题。我参与的项目中的当前案例就是您所描述的（LibA 的源代码保存在 ProjectB 中，这很糟糕），但我正在寻找一种将 LibA 保留为 LibA 并将 ProjectB 保留为 ProjectB 的方法。我希望，在客户端，LibA 和 ProjectB 的代码以某种方式驻留在一起，以便我可以编译项目，但它们的版本控制绑定应该分开（LibA 到 LibA 和 ProjectB到项目B。）