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

Question

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

Answer 1

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

• 存储外部第三方库。
  通常会将它们存储到Maven存储库中，但是要将它们存储到SVN中，您可以根据需要使用 一个且只有一个参考 ：获取您的资源，并获取您的资源您需要编译这些源的库。全部来自一个存储库。

（正如2017年ivorujavaboy所指出的那样：“现在这样做的唯一理由是，如果你有STATIC库永远不会改变，这是一个非常罕见的案例”）

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

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

---

话虽如此：

• Wim Coenen正确地mentions the disadvantages（不良做法，来源和存储交付之间的缓慢，不匹配）
• Vladimir the use of a delivery referential的倡导者（Nexus或弗拉基米尔提及Apache ivy）
• RogerV说明了the advantages of using said delivery referential（在他的案例中是Nexus）

Answer 2

不，不要在他们的源代码旁边存储二进制文件（除非你有充分的理由抵消这些缺点）。

缺点：

• 它鼓励大型项目中的错误构建实践。最佳实践是完全自动化构建。提交二进制文件使您可以忽略：“只需手动为已更改的部分进行构建”： - （
• 较慢的更新和提交
• 提交哪些更改源代码而不是相应的二进制文件将导致开发人员之间的混淆。你如何发现存在不匹配？
• svn update将更新二进制文件的时间戳，使您的构建工具混乱，错误地认为二进制文件比源代码更改更新。
• 会导致svn update和svn merge
的二进制文件出现虚假冲突
• 它在存储库中使用更多磁盘空间。 （根据您的项目，这可能是微不足道的。）

通常，请避免以确定的方式自动生成与其他版本化资源相关的任何内容。没有冗余 - ＆gt;没有机会出现不一致的情况。

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

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

Answer 3

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

Answer 4

许多人已经说过，这是可以接受的。

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

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

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

如果你在我们的案例中经过不太长时间后添加那些二进制文件已经不再有用了，我相信在类似的情况下我不会再这样做（但我会为一个较小的项目做）。

所以我建议你在做这件事之前先三思而后行，然后尝试预测你会有多大的成长以及可能会发生什么。

Answer 5

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

Answer 6

每当我在Subversion目录中看到一个库时，我都会问以下问题：

• 它的版本是什么？ （通常你有axis.jar而不是axis-1.4.jar）
• 为什么包括在内？ （特别是依赖于依赖关系的技巧）

如果您没有适当的依赖关系管理系统，通常无法回答这两个问题。这是Jar Hell的第一步。

我可以向Intranet存储库推荐Apache Ivy（其他人可能会发誓Maven）。使用Ivy，我从来不必将库存储到SVN中，并且总能回答上述问题。

Answer 7

是的，存放它。

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

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

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

Answer 8

我们的Java .jar文件构建在它们的.jar文件依赖项中绑定，我们正在检查svn。其中很多在实践中是多余的，但我们希望确保我们生成的每个Java应用程序构建都具有与QA一起经历的库。

但是，当我开始远程连接到存储库并进行同步时，真正让我感到恶心的是这种方法。永远只需要翻阅所有二进制库。

我们已经放弃了这种做法，现在使用Maven来管理库依赖项 - 即使是我们仍然使用ant构建的项目。没有更多的二进制文件被检入svn。由于战略的这种转变，生活在几个方面要好得多。我们可以严格控制我们所需的库依赖项版本。

对于我们的.NET构建，我的一个开发人员设计了一个解决方案，在很大程度上像Maven一样在所有依赖管理方面工作，并且也在那里实现了同样的好处。

Answer 9

如果您使用Java进行开发，则可以设置local repository，然后使用maven或ivy + ant等工具来访问它。< / p>

您可以将本地构建工件的更新上传回本地存储库，因为它们已准备好供公司中的其他人使用。

对于其他开发环境，我不知道有哪些类似上面的工具可用 - 我倾向于将它们放在SVN中并完成它。

我通常使用一个单独的存储库来存储第三方库，使它们不在常规开发存储库中，并让我的构建文件将它们加载到相对于项目基础文件夹的预期位置。

实际上，我使用了两个存储库。一个用于构建我的项目所需的最小文件（例如jar，lib文件）和另一个用于整个第三方软件包（包括源代码，文档或其他），我通常存储tar.bz2。

这样，如果您只想获得构建内容所需的最小值，那么您可以获取第一个存储库，如果您需要弄清楚发生了什么，或者如何使用第三方软件包，您可以开始从第二个存储库中提取东西。

这不是理想的解决方案，但效果非常好。

Here是关于svn如何处理二进制文件的更多信息。

Answer 10

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

Answer 11

我会让我的构建和持续集成系统处理最新的工作版本，通过自动将它们复制到FTP，Web或文件共享以便于访问。

更好的是我会投资自动处理构建工件的CI系统，我自己喜欢来自jetbrains的TeamCity，但还有其他人。这样你就可以全自动地处理它。

Answer 12

在版本控制下存储二进制文件可能会破坏版本控制的目的。你最好使用HTTP / FTP ..在https://stackoverflow.com/questions/104453/version-control-for-binaries上关于SO的讨论可能会有用！

Answer 13

存储并非每个人都可以构建的二进制文件。我用Verilog和VHDL设计芯片，软件团队没有这些工具。所以我们将输出二进制文件存储在SCM中。

Answer 14

在这件事上有一些争论，但我说是的。

Answer 15

至少我将二进制文件存储在SVN中，这样我就可以快速恢复到特定版本的二进制文件并查看错误是否发生在其中并跟踪版本，引入了错误，而不是检查整个项目，设置所有特定的项目相关和环境设置，然后进行编译。