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

我们希望共享运行时项目二进制文件。所以每个团队成员都可以使用当前的工作版本。

---

在SVN中存储运行时二进制文件是可以接受的/好的？

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

在这个问题上有一些争论，但我说是的。

我想说，如果这能让你的团队的生活更轻松，那就这么做吧。如果这样可以减少设置工作开发环境所需的时间，那就去做吧。

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

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

• 存储外部第三方库
  通常会将它们存储到Maven存储库中，但将它们存储到SVN中允许您拥有一个且只有一个引用，以满足您的所有需要：获取您的源代码，并获取您编译这些源代码所需的库。所有这些都来自一个存储库

（正如2017年所指出的：“目前这样做的唯一好理由是，如果您拥有永远不会改变的静态库，这是非常罕见的情况”）

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

因此，是的，在SVN中存储运行时二进制文件是“可以接受的/好的”。。。因为正确的理由

---

也就是说：

• 正确地（不良做法、速度慢、源和存储传递之间不匹配）
• 拥护（Nexus，或者如Vladimir所述，）
• （在他的案例中是Nexus）

是的，保存它

我们曾经将交付给客户的二进制文件存储在SVN存储库中，以跟踪它

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

---

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

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

---

更好的是，我会投资一个自动处理构建工件的CI系统，我自己也喜欢jetbrains，但还有其他的。通过这种方式，您可以完全自动地处理它。

在版本控制下存储二进制文件可能会破坏版本控制的目的。您最好使用HTTP/FTP。关于SO at的讨论可能会有用

我们的Java.jar文件构建是在其.jar文件依赖项中绑定的，我们正在将其签入svn。这在实践中是多余的，但我们希望确保我们生产的每一个Java应用程序构建都有经过QA的库

然而，这种方法真正让我恼火的是，当我开始远程连接到存储库并进行同步时。只需翻阅所有二进制库就要花很长时间

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

---

对于我们的.NET版本，我的一位开发人员设计了一个解决方案，在很大程度上类似于Maven，在所有依赖关系管理方面都能发挥作用，并且在那里也获得了几乎相同的好处。

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

如果您使用Java开发，然后您可以设置一个，然后使用类似或+的工具访问它

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

对于其他开发环境，我不知道有哪些类似于上述的工具可用——我倾向于将它们放在SVN中，然后使用它

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

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

那样的话，如果你只想得到你所需要的最少的东西，你就抓住它