应用程序依赖的库是否应该存储在源代码管理中？我的一部分说它应该和另一部分说不.添加一个让整个应用程序相形见绌的20mb库只是因为你依赖它的几个功能(虽然相当重)但感觉不对.你应该只存储jar/dll甚至是项目的分布式zip/tar吗？
其他人做什么？
存储10年后构建项目所需的一切.我存储任何库的整个zip分发,以防万一
编辑2017年:这个答案没有很好的年龄:-).如果您仍在使用像蚂蚁或品牌这样的旧东西,则上述内容仍适用.如果您使用更现代的东西,如maven或graddle(或者例如Nuget on .net),使用依赖关系管理,除了版本控制服务器之外,您还应该运行依赖关系管理服务器.只要您对两者都有良好的备份,并且您的依赖关系管理服务器不删除旧的依赖关系,您应该没问题.有关依赖关系管理服务器的示例,请参阅Sonatype Nexus或JFrog Artifcatory等.
除了在您的存储库中拥有第三方库之外,还应该以这样的方式进行操作,以便在将来更新库中轻松跟踪和合并(例如,安全修复程序等).如果您使用适当的供应商分支使用Subversion 是值得的.
如果你知道在你修改你的第三方代码之前是一个寒冷的日子,那么(正如@Matt Sheppard所说)外部有意义并且给你额外的好处,它变得很容易切换到该库的最新版本应该是安全更新或必备的新功能.
此外,您可以在更新代码库时跳过外部,以便在需要的长缓慢加载过程中保存.
@Stu Thompson提到在源代码管理中存储文档等.在更大的项目中,我将整个"客户"文件夹存储在源代码管理中,包括发票/账单/会议纪要/技术规格等.整个射击比赛.虽然,嗯,请记住将它们存储在SEPARATE存储库中,而不是将其提供给:其他开发人员; 客户端; 你的"浏览器源视图"......咳嗽...... :)
不要存储库; 他们并没有严格地说你的项目的一部分,并且在你的修订控制系统中占用空间.但是,请使用maven(或Ivy for ant builds)来跟踪项目使用的外部库的版本.您应该在组织内运行repo的镜像(备份),以确保始终拥有您所控制的依赖项.这应该给你两全其美; 项目外部的外部罐子,但仍然可靠且可集中访问.
我们将库存储在源代码控制中,因为我们希望能够通过简单地检查源代码并运行构建脚本来构建项目.如果您无法获得最新信息并且只需一步构建,那么您以后就会遇到问题.
永远不要将第三方二进制文件存储在源代码管理中 源控制系统是支持并发文件共享,并行工作,合并工作和更改历史记录的平台.源代码管理不是二进制文件的FTP站点.第三方程序集不是源代码; 他们每个SDLC可能会改变两次.希望能够清理您的工作区,从源代码控制和构建中删除所有内容并不意味着第三方程序集需要卡在源代码管理中.您可以使用构建脚本来控制从分发服务器中提取第三方程序集.如果您担心控制应用程序的哪个分支/版本使用特定的第三方组件,那么您也可以通过构建脚本来控制它.人们已经提到了Maven for Java,你可以用MSBuild为.Net做类似的事情.
我通常将它们存储在存储库中,但我同情你希望保持尺寸不变.
如果你不将它们存储在存储库中,绝对需要以某种方式存档和版本化,并且你的构建系统需要知道如何获取它们.Java世界中很多人似乎都使用Maven自动获取依赖关系,但我没有使用过I,所以我不能真正推荐或支持它.
一个好的选择可能是保留第三方系统的单独存储库.如果您使用的是Subversion,则可以使用subversion的外部支持来自动检出另一个存储库中的库.否则,我建议保留一个内部匿名FTP(或类似)服务器,您的构建系统可以自动从中获取需求.显然,您需要确保保留所有旧版本的库,并将所有内容与存储库一起备份.
我所拥有的是一个内部网Maven类存储库,其中存储了所有第三方库(不仅是库,而且它们各自的源代码分发包含文档,Javadoc和所有内容).原因如下:
为什么要将未更改的文件存储到专门用于管理更改文件的系统中？
它大大加快了结账时间
每当我看到源代码管理下存储的"something.jar"时,我会问"它是哪个版本的？"
京公网安备 11010802040832号 | 京ICP备19059560号-6 