将框架运行时存储在源代码控制下是一种好习惯吗？

我知道很多软件商店都将二进制文件置于源代码控制之下。但是，我们的商店开始将整个框架存储在资源库中：DirectX运行时，CUDA，nVidia Optix等。

据说可以简化开发机器的设置（据说，获取最新版本并开始编码）。但是，它极大地膨胀了存储库，并给它带来了不相关的历史负担。

我从未见过这样的用法模式。您认为这是一种好习惯吗？

[编辑：]我对源代码控制隔离的第三方二进制文件没有问题。这个问题涉及整个框架运行时，通常包含10多个二进制文件。作为一个极端的示例，请使用Windows SDK（感谢上帝，我们没有保留它在存储库中，但我认为原则上没有区别）。

二进制文件通常不太适合版本控制系统，因为：

• 他们没有从版本控制功能（合并，差异）中受益
• 他们增加了仓库的规模...
• ...之所以重要，是因为您不容易从VCS中删除一个版本（VCS是为了保留历史记录），而不是像Nexus这样的工件存储库，它们是简单的共享目录（易于清理：+ ！）cdrm
• 它们应在VCS中作为文本，路径+版本的声明进行引用：您可以以这种方式保留相关历史记录，将二进制版本的任何更改记录为该文本文件中的更改（例如，如果使用Nexus，则为pom.xml）例如）

我可以控制版本的二进制资产。我反对版本控制生成的文件。

此外，环境设置与开发有所不同。我们主要使用Python开发，它具有一个称为virtualenv的工具，可让您为项目创建轻量级的隔离环境（包括库）。当我们检查源代码时，我们在其中有一个安装脚本来构建此virtualenv。使用清单，它指定需要哪些版本的库以及其他类似的东西。这些都不是版本控制的。只有安装脚本。

将整个框架扔到主项目下将使您的历史混乱，并使事情严重混乱。它不是您的项目的一部分，应该区别对待。

使用框架版本进行配置管理通常是一个好主意。如果您的代码需要特定的DirectX版本，则该版本应该容易获得，并且如果您签出软件的旧版本，则应该很容易确定它具有哪些外部依赖项。

我认为这里不是一个好主意，是使用典型的版本控制系统来存储这些二进制文件。在我们公司中，我们将框架，库和外部工具的每个版本存储在网络驱动器上的子文件夹结构中。在我们认为合理的地方，我们拥有自述文件来记录哪个工具版本属于哪个软件版本，或者，如果可能的话，我们具有用于安装或使用特定版本的脚本。仅那些自述文件和脚本进入版本控制。

只要我们认为有可能必须重新构建较旧版本的工具和库，我们就保留它们的旧版本，具体取决于那些工具。这样一来，我们便有可能在弃用某些非常老的libs和工具时从网络驱动器中删除它们（当然，以防万一我们在外部媒体上有存档）。

我认为二进制文件应该存储在某个地方。我建议将它们存储在存储库之外，尤其是如果它们很大并且导致大量的检出时间。我不会看到这是一种不好的做法，但这也不是我所见过的。

如果您的组织中有许多针对不同运行时版本的项目，那么这实际上是一个好主意。当您在正确的项目上工作时，它可以确保您具有正确的运行时二进制文件。

我个人认为这是非常不好的做法。我更喜欢使用安装说明来设置Wiki，并向其上传必要的二进制文件。这些文件仅由新开发人员使用，而无需膨胀其他所有人的存储库。

这是一个很好的理由这样做，即你把所有你需要一个位置，无需任何外部的依赖。

这比您想象的重要得多。从本质上讲，这确保您不会依赖供应商服务器上的工件，该工件可能会在几年后消失，因为您拥有的一切都在内部。

关于仓库膨胀。如果您的VCS保留完整的本地副本（git执行此操作，cvs不执行），这只是一个问题，因为克隆和/或更新将很慢。作为回报，您将在每台开发计算机上拥有副本，如果您的中央备份方案由于某种原因而失败的话，这可以为您的公司省钱。

这是优先事项或政策问题。只要决定是有意的，我对此就可以了。