是否将生成工具保留在版本控制中?

关于这一点,有两个学派:

1. 放 只是 将源代码放入存储库。
2. 把构建软件所需的一切(除了操作系统和语言运行时)都放到存储库中。

我个人更倾向于2,因为它使有人更容易启动和运行我的代码。无论如何,我认为,如果你选择第一种方法,你至少应该做到让一个人可以 得到 第2点要求的东西和源代码在一个步骤中,即使不一定由版本控制实现。

不幸的是,构建系统是一个灰色地带。除非我用的是模糊的或非标准的东西,否则我会把它忽略掉。而那些晦涩和不规范的东西是由你工作的环境决定的。例如,如果您的公司总是使用msbuild,但出于任何原因决定在这个项目中使用nant,那么我将把它包括进来。

是的,我保留了在版本控制中交付软件产品过程中的所有内容。

我把建筑 脚本 在版本控制下,但不是工具。通常情况下,i版本文件是应用程序核心的一部分,或者在项目的生命周期中可能经常更改(每个人都需要访问这些更改)。这包括几乎所有的配置文件。

我通常在Java项目上使用Eclipse/Ant。不,我不将JDK、Ant或Eclipse保持在版本控制之下,但是:

• 我所有的来源
• 生成脚本
• 所有使用版本的第三方库(是,也包括JUnit)

原因:我有一个几乎独立的构建系统,任何安装了JDK和Ant的系统都可以构建,而无需网络连接(外部JavaDoc的包列表也已签入)。这可以是我的MacBook,公司的Windows桌面,任何持续的构建服务器。

我们使用 maven ,所以我们只检入代码、测试、配置文件,当然还有pom.xml,没有libs,没有工具。

我放置了makefiles、shell脚本和我在版本控制中编写的任何代码生成器。我不会在版本控制中存储二进制文件,除非有无法从源代码轻松构建的库。

通常,我只向版本控制添加可能由我自己或与我一起工作的其他人维护的项。一个外部库通常被一个项目所消耗——大多数不在业务中的项目都在重新编写它们所依赖的库。

我建议您添加 定制 到版本控制。对于其他一切,您只需将包保存在一个公共位置。无需使用永远不会从标准发行版更改的代码来扩充存储库。

我们不将工具放在来自外部的SVN中(Visual Studio、Eclipse、CDT插件…)。

但是我们有一套自编的工具(代码生成器、针对VS的定制构建组件和Eclipse插件),在这些工具中我们将源代码和二进制代码放入SVN。

做出这一决定的原因很简单,技术方面:

• 我们的工具非常小,运行时不需要显式的设置例程(因此,一个简单的SVN签出会给您留下一组正在运行的工具)
• 我们的工具比第三方工具变化更频繁(因此我们不需要告诉开发人员每月更新3次工具)

对!这就是我的答案。

我把诸如nunit和nant这样的构建工具放在版本控制中。

我的主要规则是:

• 生成服务器必须能够生成解决方案。

我使用的构建服务器没有安装nunit、nant等。

构建服务器已经得到了.NET框架和CruiseControl.NET,其他的就不多了……

我们沿着一条不同的路径建立了一个虚拟机,在这个虚拟机上构建了我们的发行版。然后将其存档(但出于某种原因不在修订控制系统中)。

只要我们有一台可以承载虚拟机的机器,我们就可以重新创建二进制文件。让我们独立于底层操作系统。

有几个问题让Lisince经理启动和运行,但在那之后一切都很好。

没有。大多数开发商店都有一套相当标准的工具。不过,有一个想法是保留一个标准的“快速设置”wiki或类似的深度链接,以便为所有需要的构建工具安装程序。写下来,这样一个相对来说没什么过期的人就可以很容易地建立一个开发机器。更高级的选择是保留一个包含所有内容的标准虚拟硬盘。

但是,我们会将其他所有内容保留在源代码管理中—所有构建脚本、SQL脚本、文件依赖性(即引用的DLL未安装在GAC或程序文件中)等。

我们是一家小牛店,以前是一家蚂蚁店。在Ant时代,我们会将依赖库检查到项目结构中。现在,我们只检查构建应用程序所需的资源(POM、源代码、资源等),但肯定没有库。

我们保留两个存储库:“快速移动的存储库”包含我们的代码,带有发布和补丁的分支。

缓慢移动的版本包含第三方库和工具,包括JDK版本。大多数情况下都没有分支或标记,因为另一个代码知道如何选择它需要的内容。同一个库的两个版本以不同的名称签入,因此两个版本在签出后都可用。我们自己的一些交叉发布工具也包含在这个存储库中。不包括IDE,因为它们不是正式构建过程的一部分。

在某种类型的存储库中存储工具有两个原因:

1. 任何开发人员都可以很容易地找到他们需要的工具。
2. 可以创建过去任何正式构建的复制,以便生成补丁。

“不,我不这样做”的回答让我很惊讶。除非您具有编写代码所依据的依赖项的特定版本,否则无法可靠地构建代码库。因此,这将包括您正在引用的任何DLL,如单元测试和模拟框架、UI控制集等。

开发人员应该能够完成一个签出,并且只需几个步骤就可以进行构建。有些地方需要一整天。

我们没有——事实上,我从来没有为这样的地方工作过。

我们确实在源代码管理中保留了makefiles、构建脚本和测试脚本之类的东西,但从不保存ant或c编译器之类的东西。

原因是,通常需要的不仅仅是简单的签出才能使构建工具处于可用状态,而且您需要执行一些繁重的系统管理工作来同时维护多个版本或在版本之间切换。因此,将它们保持在源代码控制中可以解决问题的一小部分。

不是工具,而是脚本。我们使用 Ant . 驱动进程的build.xml脚本受源代码管理。

就我个人而言,我更喜欢将尽可能多的构建工具放在存储库中,但是我在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框架)。

代码、构建、测试、文档和任何其他自动化。我通常还会将时间表和任何其他与项目相关的文档放在存储库中。

对于大多数项目,如果我有依赖库的源代码,我通常将它们放在自己的存储库中,这样我就可以随着时间的推移跟踪对它们的更改。

至于可安装包中的预打包工具,我将它们都保存在可访问服务器上的一个大目录树中(使用旧版本)。这样,我可以将任何新开发人员指向dir,并告诉他们要安装什么(并且知道他们与团队的其他成员拥有相同的版本)。我会使用一个存储库,但这太过分了,共享文件系统更容易被每个人访问。保留旧版本以防出现支持问题。

保罗。

存储库中的内容:

• 我写的任何代码或我的学生写的任何代码

• 所有生成文件、测试脚本和该ILK的内容

• 我们修改过的外部工具(我们通常放入整个工具,而不仅仅是补丁) 包括安德鲁·休姆的版本

不进去的东西:

• 我们使用的所有编译器的源代码

• 外壳的源

如果我们有更好的工具,我们会把它 全部的 到存储库中。对于一本关于如何做到这一点并从一开始就跟踪所有版本的书,请查看Digital SRC上的书 Vesta project .

不,绝对不是。从未。你的风投应该只包含你的代码。如果您想确保有人能够快速安装您的代码,您需要提供一个分发系统。希望安装您的代码的人应该使用打包的二进制发行版或从源tarball构建。他们不应该从风投那里建立。分发tarball是放置项目构建所必需的东西的地方,但这些东西要么是自动生成的,要么不是项目的直接部分。然而,它不是依赖关系的地方。如果您的项目需要Boost库,那么它应该在文档中声明为依赖项,如果没有安装,那么您的构建应该失败。来自源tarball的用户构建应该能够安装依赖项。从打包的二进制发行版构建的用户期望包系统处理依赖性问题。从VCS(即开发人员)构建的用户需要安装项目所需的构建工具。

我尝试使用虚拟机作为构建系统。
并为每个项目存储这些(在最好的情况下)。

在所有工具中使用tarball或存储库的主要问题是:
安装它们花费了太多的时间,而且在几年后,你总是会遇到一些问题让它重新工作。

也可以通过脚本下载,或者简单地告诉你,在几年后,网络源会变得不稳定,你会得到一些带有其他特性和错误的更新版本。

有时它只是无法在较新的操作系统版本上安装构建系统。
或者,某些工具的较新版本(如Visual Studio 2025)将使用其他项目文件,“完全向上兼容性”失败。

而且,许可证在几年后会出现问题,您能在合理的时间内获得新的激活密钥吗?公司还是支持它吗?

虚拟机只包含所有必要的已安装工具,并在几分钟后运行。
很好,特别是如果我只想更改几行代码。

不,我没有,因为我使用了msbuild,而且它还是.NET框架的一部分。