您是否将构建项目所需的工具置于版本控制之下？
如果您这样做，您对包含哪些工具的指导方针是什么？我想没有人将 Visual Studio 置于版本控制中，但你的单元测试运行器呢？ Nant/Ant/Maven 可执行文件？
外部依赖如何？你在版本控制中有 Boost 吗？ JDK？ NUnit/JUnit？您在哪里划定界限？
（另见this question）。
编辑： 我想我的问题并不完全清楚：我不想知道您是否将它们保留在版本控制中或某些共享驱动器中。我真的很想知道您是否将构建项目所需的工具与项目一起签入版本控制，以便在签出项目时自动获取这些工具。
作为对那些回答“否”的人的一般跟进：您跟踪这些工具的流程是什么？你的脚本会下载它们吗？
【问题讨论】：
标签： svn version-control
是的，我将交付软件产品过程中的所有内容都保留在版本控制中。
【讨论】：
对此有两种观点：
我个人更倾向于#2，因为它使某人更容易启动和运行我的代码。无论如何，我认为如果您选择第一种方法，您至少应该这样做，以便人们可以一步获得第 2 点所需的东西和您的源代码，甚至如果不一定通过版本控制。
不幸的是，构建系统有点像灰色地带。我个人将它排除在外，除非我使用一些晦涩或非标准的东西。什么晦涩难懂和不标准取决于你工作的环境。例如，如果你的公司总是使用 MSBuild，但出于任何原因决定在这个项目中使用 Nant，那么我会包含它。
【讨论】：
我将构建脚本置于版本控制之下，而不是工具。通常，我版本的文件要么是应用程序核心的一部分，要么可能在项目的生命周期内频繁更改（并且每个人都需要访问这些更改）。这包括几乎所有的配置文件。
【讨论】：
我通常在 java 项目中使用 eclipse/ant。不，我不会将 JDK、Ant 或 eclipse 置于版本控制之下，但是：
原因：我有一个几乎独立的构建系统，任何安装了 jdk 和 ant 的系统都可以构建，无需网络连接（外部 javadoc 的包列表也已签入）。这可以是我的 macbook、公司的 windows 桌面、任何连续的构建服务器。
【讨论】：
我们使用maven，所以我们只签入代码、测试、配置文件，当然还有 pom.xml，没有库，没有工具。
【讨论】：
我将 makefile、shell 脚本和我编写的任何代码生成器放入版本控制中。我不会将二进制文件存储在版本控制中，除非存在无法从源代码轻松构建的库。
【讨论】：
通常，我只将可能由我自己或与我一起工作的其他人维护的项目添加到版本控制中。外部库通常由项目使用 - 大多数不在业务中的项目都在重写它们所依赖的库。
我建议将您自定义的工具添加到版本控制中。对于其他所有内容，您只需将包保存在一个公共位置即可。无需使用永远不会从标准发行版更改的代码来膨胀您的存储库。
【讨论】：
我们不会将来自外部（Visual Studio、Eclipse、CDT-Plugin、...）的工具放入 SVN 中。
但我们有一大套自行编写的工具（代码生成器、用于 VS 的自定义构建组件和 Eclipse 插件），我们将源代码和二进制文件放入 SVN。
做出这个决定的原因很简单：
【讨论】：
是的！是我的答案。
我将 NUnit 和 NAnt 等构建工具放入版本控制中。
对我来说主要的规则是：
而且我使用的构建服务器没有安装 NUnit、NAnt 等。
构建服务器有 .NET 框架和 CruiseControl.NET，其他的不多......
【讨论】：
我们走了一条不同的路径来设置我们在其上进行发布构建的 VM。然后将其存档（但由于某种原因没有进入修订控制系统）。
只要我们有一台可以托管 VM 的机器，我们就可以重新创建二进制文件。让我们独立于底层操作系统。
在启动和运行许可管理器时遇到了一些问题，但之后一切都很好。
【讨论】：
没有。大多数开发商店都有一套相当标准的工具。不过，一个想法是保留一个标准的“快速设置”wiki 或类似的，为所有需要的构建工具提供安装程序的深层链接。编写它，以便经验相对较少的人可以轻松设置开发机器。一个更高级的选择是保留一个包含所有内容的标准虚拟硬盘。
我们会这样做，但是将所有其他内容保留在源代码控制中 - 所有构建脚本、SQL 脚本、文件依赖项（即未安装在 GAC 或程序文件中的引用 dll）等。
【讨论】：
我们是一家 Maven 商店，之前是一家 ANT 商店。在 ANT 时代，我们会将依赖库检查到项目结构中。现在我们只检查构建应用程序所需的资源（pom、源代码、资源等），但绝对没有库。
【讨论】：
我们保留 2 个存储库：“快速移动的”包含我们的代码，以及用于发布和补丁的分支。
缓慢移动的包含 3rd 方库和工具，包括 JDK 版本。其中大部分没有分支或标记，因为另一个中的代码知道如何选择它需要的内容。同一库的两个版本以不同的名称签入，因此在签出后两者都将可用。我们自己的一些交叉发布工具也包含在这个存储库中。 IDE 不包括在内，因为它们不是官方构建过程的一部分。
将工具存储在某种存储库中的原因有两个：
【讨论】：
我对所有“不，我不这样做”的回答感到非常惊讶。除非您拥有编写代码所针对的特定版本的依赖项，否则您无法可靠地构建代码库。因此，这将包括您引用的任何 DLL，例如单元测试和模拟框架、UI 控件集等。
开发人员只需几个步骤即可完成结帐和构建。有些地方需要花上一整天时间。
【讨论】：
我们没有——事实上，我从来没有为这样的地方工作过。
我们确实在源代码控制中保留了 Makefile 和构建脚本和测试脚本之类的东西，但从不保留 ant 或 C 编译器之类的东西。
原因是，要让构建工具进入可用状态，通常需要的不仅仅是简单的检查，而且您需要执行一些繁重的系统管理员工作来同时维护多个版本或在版本之间切换。因此，将它们保留在源代码管理中将解决问题的一小部分。
【讨论】：
不是工具，而是脚本。我们使用Ant。驱动进程的 build.xml 脚本受源代码控制。
【讨论】：
就个人而言，我更喜欢将尽可能多的构建工具放在存储库中，但我在 IDE 和编译器上划清界限。
我喜欢将其视为一种权衡：我可以选择：
对于 IDE 之类的东西，只记录它更容易，而且大多数开发人员已经安装了它。对于 Ant、Nant、JUnit 等，更容易将其包含在存储库中。
我特别喜欢在存储库中使用 Ant/Nant，因为它允许我包含这样的 go.bat/go.sh-script：
set ANT_HOME=tools/apache-ant-x.x.x
tools/apache-ant-x.x.x %*
然后我可以随时签出一个项目，运行“go”，它应该构建项目（假设我安装了 JDK/.Net 框架）。
【讨论】：
代码、构建、测试、文档和任何其他自动化。我通常什至将时间表和任何其他与项目相关的文档也放在存储库中。
对于大多数项目，如果我有依赖库的源代码，我通常会将它们放在它们自己的存储库中，这样我就可以随着时间的推移跟踪它们的变化。
至于可安装包中的预打包工具，我将它们全部保存在可访问服务器上的一个大目录树中（使用旧版本）。这样，我可以将任何新开发人员指向目录并告诉他们要安装什么（并且知道他们与团队其他成员具有相同的版本）。我会使用存储库，但这有点过头了，而且共享文件系统更容易被每个人访问。保留旧版本以防出现支持问题。
保罗。
【讨论】：
什么进入我们的存储库：
我或我的任何学生编写的任何代码
所有 Makefile、测试脚本和类似的东西
我们修改的外部工具（我们通常会放入整个工具，而不仅仅是补丁） 包括 Andrew Hume 的 Make 版本
什么不进去：
我们正在使用的所有编译器的源代码
shell 的来源
如果我们有更好的工具，我们会将其全部放入存储库。要获得一本关于如何做到这一点并跟踪自一开始以来所有版本的好书，请查看 Digital SRC Vesta project 上的书。
【讨论】：
没有。绝对不。绝不。您的 VCS 应该只存放您的代码。如果你想确保有人可以快速安装你的代码，你需要提供一个分发系统。希望安装您的代码的人应该使用打包的二进制发行版或从源代码 tarball 构建。他们不应该从 VCS 构建。分发 tarball 是放置项目构建所必需的东西的地方，这些东西要么是自动生成的，要么不是你项目的直接部分。然而，它不是依赖的地方。如果您的项目需要 boost 库，则应在文档中将其声明为依赖项，如果未安装，您的构建将失败。从源 tarball 构建的用户应该能够安装依赖项。从打包的二进制发行版构建的用户期望包系统处理依赖问题。从 VCS 构建的用户（即开发人员）需要安装项目所需的构建工具。
【讨论】：
我尝试始终使用虚拟机作为构建系统。
并为每个项目存储这些（在最好的情况下）。
在所有工具中使用 tarball 或存储库的主要问题：
安装它们要花费太多时间，而且几年后您总是会遇到问题，以使其再次工作。
也可以通过脚本下载或仅告诉网络源在几年后不稳定，您将获得一些具有其他功能和错误的更新版本。
有时只是无法在较新的操作系统版本上安装构建系统。
或者某些工具的较新版本（如 Visual Studio 2025）将使用其他项目文件，并且“完全向上兼容”失败。
而且许可证在几年后出现问题，您能否在合理的时间内获得新的激活密钥？公司是否仍然支持它？
虚拟机只包含所有必要的已安装工具，并在几分钟后运行。
很好，特别是如果我只想更改几行代码。
【讨论】：
不，我不这样做，因为我使用 MsBuild，而且无论如何它都是 .NET 框架的一部分
【讨论】：