在SVN中存储二进制文件是否可接受/好？

Question

我们想共享运行时项目二进制文件.因此每个团队成员都可以使用当前的工作版本在SVN中存储运行时二进制文件是可以接受/好的吗？

Answer 1

您可能希望在版本控制系统中存储二进制文件的两个常见原因是(2009年编写):

存储外部第三方库.
通常会将它们存储到Maven存储库中,但是要将它们存储到SVN中,您可以根据需要获得一个且仅有一个参考:获取源代码,并获取编译这些源所需的库.全部来自一个存储库.

(正如2017年ivorujavaboy所指出的那样:"目前唯一能做到这一点的理由就是你拥有永不改变的STATIC库,这是一个非常罕见的案例")

存储交付以便更快地部署.
通常,交付(您构建以部署到生产中的可执行文件)是按需构建的.
但是,如果您有许多预生产环境,并且如果您有许多交付,那么构建它们用于组装,集成,认证,预生产平台的成本可能很高.
解决方案是构建它们一次,将它们存储在SVN的交付部分中,并直接在不同的环境中使用它们.
注意:
这也适用于开发元素:如果您有一个生成900个POJO文件的Jaxb进程(通过XML绑定),并且您需要在多个环境中下载该开发集,则可能需要1个压缩文件复制事务,而不是900个那些.

所以,是的,"在SVN中存储运行时二进制文件是可接受/好的"......出于正确的原因.

话虽如此:

@Rob:a /如果他们经常更改并且b /如果你需要检索旧版本,那么是.如果没有,像Nexus这样的其他存储库(不是基于VCS的)将确保这些元素的一些历史记录,并且您将能够比在VCS中更容易地从存储库中删除它们. (3认同)

Answer 2

不,不要在其源代码旁边存储二进制文件(除非您有充分的理由抵消这些缺点).

缺点:

通常,避免以确定的方式从其他版本化资源提交任何自动生成的内容.没有冗余 - >没有出现不一致的机会.

相反,使用持续集成服务器在每次提交时自动重建(并运行测试).如果需要,让这个构建服务器在某处(SVN外部)发布二进制文件.

现在,这并不意味着您应该将此视为绝对规则或避免使用所有二进制文件.无论如何,将构建工具和第三方闭源二进制文件放在项目中.并在有意义时制作例外.理想情况下,新开发人员应该能够执行签出并立即启动构建脚本,而无需花费一两天时间来设置其环境.

Answer 3

我会说,如果它让你的团队生活更轻松,那就去做吧.如果它减少了设置工作开发环境所需的时间,那就去吧.

Answer 4

正如许多人已经说过的那样,这是可以接受的.

是的,方便的是从一个位置获得一切便利,从那里你可以(例如)以二进制形式检查已经具有正确依赖关系的旧标签.

但它并不好,特别是对于备份目的.我们将所有二进制文件(以及部分依赖项)存储在SVN中,随着项目的增长,二进制文件就这样做了.

不幸的是,svnadmin dump只是转储所有内容,您无法指定要排除的存储库的路径.因此,备份(以及svn服务器的升级)变得非常痛苦!

如果你在我们的情况下在不太长的时间之后添加那些二进制文件已经不再有用,我相信在类似的情况下我不会再这样做(但我会为一个较小的项目做).

所以我建议你在做之前先三思而后行,然后尝试预测你能成长多少以及其他可能发生的事情.

Answer 5

不是为了这个目的,不.您应该使用外部文件存储,如FTP或Web服务器.这样,您可以轻松下载特定版本的运行时二进制文件,而无需先在SVN中更新该版本.

Answer 6

每当我在Subversion目录中看到一个库时,我会问以下问题:

如果您没有适配器管理系统,通常无法回答这两个问题.这是Jar Hell的第一步.

我可以推荐使用Intranet存储库的Apache Ivy(其他人可能会发誓Maven).使用Ivy,我从来没有将库存储到SVN中,并且总能回答上述问题.

Answer 7

是的,存放它.

我们过去常常将我们提供给客户的二进制文件存储在SVN存储库中以跟踪它.

另外,在SVN(或源代码控制)中存储二进制文件的另一个用途是,如果要向公司中不想构建项目以节省构建时间的其他团队提供一些内部实用程序模块.我相信这是一种常见的做法.

但我们从未允许存储Eclipse的.classpath和.project文件(工作区相关设置).

Answer 8

将二进制文件存储在 SVN 存储库中是完全可以接受的。作为旁注，我不明白为什么有人想要将构建工件存储在存储库中（我并不是说你这样做）。