支持和反对包含版本控制中的第三方库的参数？

Question

我最近见过很多人说第三方库不属于版本控制.这些人还没能向我解释他们为什么不应该这样做,所以我希望你们能来救我:)

就个人而言,我认为当我检查一个项目的主干时,它应该工作 - 不需要去其他网站找到库.通常情况下,您最终会为不同的开发人员提供相同第三方库的多个版本 - 有时会出现不兼容问题.

有一个libs文件夹是不是很糟糕,你可以参考"guarenteed to to-work"库？

Answer 1

在SVN中,有一种模式用于存储称为供应商分支的第三方库.同样的想法适用于任何其他类似SVN的版本控制系统.基本思想是将第三方源包含在其自己的分支中,然后将该分支复制到主树中,以便您可以轻松地在本地自定义上应用新版本.它也干净利落地保持分开.恕我直言,直接在你的树中包含第三方内容是错误的,但供应商分支达到了很好的平衡.

Answer 2

检查库中的源代码控制的另一个原因是我在这里没有提到,它使您能够从特定的快照或版本重建应用程序.这允许您重新创建某人可能报告错误的确切版本.如果您无法重建确切版本,则可能无法重现/调试问题.

Answer 3

是的,你应该(如果可行的话).

您应该能够使用新机器并使用尽可能少的步骤构建项目.对我来说,它是:

1. 安装IDE(例如Visual Studio)
2. 安装VCS(例如SVN)
3. 查看
4. 建立

任何事情都必须有很好的理由.

这是一个例子:我有一个项目使用Yahoo的YUI压缩器来缩小JS和CSS.YUI .jar文件在源代码管理中进入tools项目旁边的目录.然而,Java运行时没有 - 这已成为项目的先决条件,就像IDE一样.考虑到JRE的流行程度,这似乎是一个合理的要求.

Answer 4

不 - 我认为您不应该将第三方库放入源代码管理中.线索的名称是"源控制".

虽然源代码控制可用于分发和部署,但这不是它的主要功能.你应该能够检查你的项目并让它工作的论点是不现实的.总有依赖关系.在一个Web项目中,它们可能是Apache,MySQL,编程运行时本身,比如Python 2.6.您不会将所有这些都堆积到您的代码存储库中.

额外的代码库也是一样的.不是将它们包含在源代码控制中以便于部署,而是创建一个部署/分发机制,允许轻松获取和安装所有依赖项.这使得检查和运行软件的步骤如下:

• 安装VCS
• 同步代码
• 运行安装脚本(下载并安装所有依赖项的正确版本)

为了给出一个具体的例子(我意识到这是以网络为中心的),Python Web应用程序可能包含一个requirements.txt文件,其中包含:

simplejson == 1.2
django == 1.0
otherlibrary == 0.9

通过pip运行,完成工作.然后,当您想要升级到使用Django 1.1时,您只需更改需求文件中的版本号并重新运行设置.