应用程序依赖的库是否应该存储在源代码管理中？我的一部分说它应该和另一部分说不.添加一个让整个应用程序相形见绌的20mb库只是因为你依赖它的几个功能(虽然相当重)但感觉不对.你应该只存储jar/dll甚至是项目的分布式zip/tar吗？
其他人做什么？
假设您正在开发一些支持多种配置的项目(Linux和Windows构建,共享/静态链接,某些功能或没有,等等).要构建所有这些配置,您需要不同版本的第三方组件(使用gcc或msvc构建,共享/静态,具有一些指定的预处理器定义等).因此,最终您最终会遇到管理所有这些配置的问题,不仅适用于您的项目,还适用于您的项目正在使用的所有库.
是否有通用的解决方案/方法/软件来帮助管理单个项目的几种不同配置？
标准:
到目前为止,我已经尝试了几种方法.
在VCS下为每个配置存储预构建的软件包.
优点:项目很小时易于设置(更新工作副本,你很高兴).易于管理(为每个必需的配置构建一次库).错误证明(VCS客户端会通知您有关工作副本的更改).
缺点:不适用于分布式VCS(GIT,Mercurial等).存储库迅速增长,最终简单的"克隆"操作将无法容忍.您最终还会下载许多您并不真正需要的东西(例如,如果您正在使用Linux,那么就是Windows库).如果您正在实施库,那么您的库的用户将通过将其集成到他们的项目中来继承所有这些问题.
存储库源而不是预构建的包.
优点:易于设置.
缺点:添加新库非常痛苦.您需要为每个配置提供构建脚本和源补丁.但这只是冰山一角.你的依赖项有它们自己的依赖项,它们有自己的依赖项等等......你很有可能最终得到类似Gentoo发行版的东西:)
在外部服务器上的某处存储存档或仅包含预构建软件包的文件夹.
优点:解决问题......有点儿.
缺点:设置起来不那么容易(您必须手动复制存档).不太容易管理(您必须手动将每个库添加到服务器).没有变化的历史.不是错误证明,因为很容易忘记在服务器上放东西,或删除有用的东西.
稍微改进的方法:您可以使用集中式VCS(例如,SVN)来存储所有第三方库,它将更容易使用.但是,如果将其用作简单的文件存储,您或者没有集中的更改历史记录,或者如果将其用作子存储库,则会获得包含大量不必要库的大型存储库.
我们目前不使用nuget作为我们的依赖项,更喜欢采用old-skool方式并将它们全部放在libs文件夹中并从那里引用.我知道.所以1990年代.
无论如何,nuget总让我感到有些不安......你知道,依赖云和所有这一切.因此,我发现自己主要同意Mark Seeman(见这里:http://blog.ploeh.dk/2014/01/29/nuget-package-restore-considered-harmful/)谁说:
就个人而言,我总是禁用该功能,而是检查我的存储库中的所有包.这从来没有给我任何问题.
麻烦的是,这在版本3中发生了变化,您无法将解决方案与解决方案一起存储,如下所述:https://oren.codes/2016/02/08/project-json-all-the-things/.哪一种搞砸了将它们检查成源代码.
那么,我在这里什么都不担心？我应该从nuget中饮用,还是与Seeman先生和呃谨慎一起喝酒？