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