将开发工具（编译器、IDE、编辑器……）和运行时环境（jre、.net 框架、解释器……）置于版本控制之下有两个很好的理由。首先，您只需签出您的存储库即可轻松编译/运行您的程序。你不必拥有其他任何东西。其次，正如您曾经测试过的那样，三元组肯定是版本兼容的。但是，它也有其自身的缺点。主要是必须将大量的大型二进制文件置于版本控制系统之下。这可能会导致 VCS 变慢并且备份过程更难。你有什么想法？
【问题讨论】：
标签： version-control runtime development-environment
实际用于编译和构建项目的工具和依赖项，绝对是 - 如果您必须调试问题或为旧版本开发修复程序并且您已经转移到不是的新版本，这将非常有用与旧的完全兼容。
IDE 和编辑器没有 - 理想情况下，您的项目应该可以从脚本构建，因此这些不是必需的。无论您使用什么来编辑源，生成的输出应该仍然相同。
【讨论】：
我在每个项目根目录中都包含一个名为“How-to-get-this-project-running”的文本（因此很容易区分）文件，其中包括所有必要的东西，包括正确的 .net 版本和服务包。
【讨论】：
对于专有 IDE（例如 Visual Studio），也可能存在许可问题，因为这使得管理谁在使用哪些软件变得困难。
编辑： 我们还曾经在源代码控制中存储自动签出源代码（以及所有依赖项）的批处理文件。开发人员只需检查“Setup”文件夹并运行批处理脚本，而不必在存储库中搜索适当的点点滴滴。
【讨论】：
我发现非常好的和常见的（在我有经验的 .Net 项目中）是在带有源代码控制的 lib 或依赖项文件夹中包含任何“非默认安装”依赖项。运行时由 GAC 提供，并且是一种假设。
【讨论】：
首先，您只需检查您的存储库即可轻松编译/运行您的程序。
不正确：仅仅获取/复制/签出工具通常是不够的，还必须在工作站上安装该工具。
就我个人而言，我在源代码版本控制系统中看到了库和 3rd-party 组件，但没有看到工具。
【讨论】：
我将所有依赖项保存在名为“3rdParty”的源代码控制下的文件夹中。我同意这非常方便，您只需拉下源代码即可开始使用。这确实不应该影响源代码管理的性能。
唯一真正的缺点是要下拉的初始大小可能相当大。在我的情况下，任何下拉代码的人通常也会运行它，所以没关系。但是，如果您希望很多人下载源代码只是为了阅读，那么这可能会很烦人。
【讨论】：
我在不止一个工作过的地方看到过这种情况。在所有情况下，我都发现它非常方便。
【讨论】：