“磁盘”便宜的理论最近有点失控了。版本控制有一些强大的方面，使我们能够使用一些引导文件和一个简单的命令来拉动工具链来让新开发人员加入。
最近对系统的升级提示了存储构建二进制文件的请求。随后请求对整个虚拟化构建系统进行版本控制。添加到顶部的每一层都会在存储库之间创建重要的关系，并且需要良好的基础设计来管理它。
存储工具链带来即时收益，而存储构建的二进制文件带来即时负债。不幸的是，Git 在处理大型二进制文件时存在一些基本问题。
在以正确方式使用 VC 时，您在哪里划定界限？您什么时候开始研究更合适的解决方案？
【问题讨论】：
标签： svn git version-control
我想说这里有一个操作顺序：
如果他们需要存储文件，请使用文件系统。
如果他们需要跟踪更改，请使用版本控制。
如果他们需要跟踪与数据的关系，请使用数据库。
要求越复杂，解决方案就越复杂。但是纪律是为了那些想要更复杂的解决方案的人。在这些不确定的时期，我们必须避免浪费时间。
【讨论】：
我坚持存储构建最终产品所需的任何东西的经典答案。不需要二进制文件和中间文件，但包含构建中使用的任何脚本。
我使用我的 git 存储库作为备份，将裸克隆存储在至少两个地方，因此我尽量不遗漏构建所需的任何内容，但我不会费心存储任何临时的内容。
【讨论】：
没有它就无法重新创建的版本控制。因此，工具链不能轻易地重新创建——版本控制是有意义的。使用受版本控制的工具链（和源代码），无需存档构建产品 - 或者至少在构建测试完成后不需要。
【讨论】：
您可能不应该将“整个虚拟化构建系统”存储为巨大的二进制文件。如果要对应用程序进行版本控制，请对源代码进行版本控制，而不是编译后的二进制文件。
许多商店所做的是将重新创建构建服务器的步骤存储在版本控制中。然后，您需要一个固定映像（库存、开箱即用的操作系统安装），以及少量文件（在其上安装什么以及如何安装）。有些地方甚至让他们的服务器在每次部署/重启时，在干净的操作系统安装上从源代码重建应用程序。
将操作系统映像本身作为一个巨大的二进制文件进行版本控制几乎没有那么有用。你不能分支。你不能合并。你无法区分。重点是什么？如果您的 VCS 可以进行二进制差异，您可能会节省空间，但这可能需要大量的 CPU 和内存才能完成，而且如果它们处于“磁盘便宜”的狂热状态，那么没有理由仅仅为了节省而让生活变得痛苦磁盘空间。
将您的安装脚本/库存储在 VC 中并根据需要重新构建 VM 映像，或者仅将 VM 映像存储在普通文件中。我认为将图像放入 VCS 没有任何意义。
【讨论】：
应该指导您如何控制和配置您的工具链，而不是 IT 方面的繁琐。如果您拥有标准硬件并且经常添加开发人员，那么将构建的工具链存储为图像是有意义的；但图像不必受版本控制。如果您有 50 名开发人员，则工具链的配置管理系统将减少开销；如果您有 5 个开发人员，则开销更大——需要学习另一个系统。
那么，Git 是否妨碍了您想要做的事情？或者你收到请求是因为用户试图说你应该让你的系统变得更复杂，因为你可以？
如果您的构建工具已经成熟，那么构建日期可能足以确定所使用工具的版本。您可以让构建脚本轮询编写构建工具及其版本的文本文件，类似于依赖项列表。
如果您正在使用快速变化的内部工具，或者正在积极开发的项目的 alpha/beta 版本，那么将构建工具置于版本控制之下是一个很好的理由 - 但它会解决错误的问题.为什么要使用不稳定的工具链构建？？？
【讨论】：
对于一个相当极端的方法，请查看Vesta。
Vesta 方法基于以下基础：
所有源和工具的不可变、不朽、版本化存储。不像 ClearCASE，Vesta 使用明确的版本号而不是视图。
完整的、基于源的配置描述。通过完整，我们的意思是 描述命名所有有助于构建的元素。计算环境的各个方面，包括工具、库、头文件、 和环境变量，完全由 Vesta 描述和控制。经过 基于源，我们的意思是配置描述指定如何构建 仅使用不可变源（即非派生文件）从头开始的系统。 描述本身是版本化和不可变的来源，它们的 意义是不变的；一个特定的顶级描述总是描述使用相同源的相同构建，即使在新版本 来源和描述已创建。
自动派生文件管理。派生文件的存储和命名 由 Vesta 存储库自动管理，从而减轻 构建多个版本或为多个目标平台构建的负担。
所有构建工作的站点范围缓存。灶神星具有共享的站点范围缓存 构建结果，以便开发人员可以从彼此的构建中受益。
自动依赖检测。 Vesta builder 动态检测和 记录所有依赖项，因此不会因人为错误而省略。通过动态，我们的意思是构建器检测实际使用的源 构建构建结果并仅记录依赖关系的过程 他们。灶神星的依赖分析没有使用任何知识 构建工具如何工作；因此，在 Gunter [7] 的术语中，它是与语义无关的。例如，如果编译器在进程中读取文件 foo.h 在编译文件 foo.c 时，Vesta 会假设编译器的输出取决于 在所有 foo.h 上，即使具有 C 知识的工具可能能够找到 foo.h 中可以在不更改结果的情况下更改的单个项目 的汇编。
【讨论】：
我一直在版本控制中添加的内容：
我从来没有把什么放在版本控制中：
我根据项目在版本控制中添加了什么：
【讨论】：
我一直在为我的整个工具链使用源代码管理。如上所述，这有很大的好处：
我在操作系统上方某处画了线；我提交的一些内容是：
窗户
Linux
两者
我在尝试这样做时遇到的一些问题是：
crti.o 和朋友是默认情况下在/usr/lib 中找到的东西，实际上归glibc-devel（或libc6-dev）所有，所以它不在文件系统中，除非@987654331 @ 已安装。我已经开始尝试使用Apache Ivy（类似于Maven）来帮助我管理工具链，但是我还没有看到任何使用 Ivy 或 Maven 来管理不是Java .jar 文件。我不知道我是否能够管理诸如 C 编译器之类的东西。
理想情况下，我希望源代码控制签出或 Ivy 或 Maven 解析以使开发人员文件系统中的每个工具和库都可以使用。但是我开始认为，要求开发人员安装少量关键的东西，比如 Windows SDK，或者gcc 和glibc-devel 包并不是一个坏主意。如上所述，这是一个 5 或 50 名开发人员的问题，以及创建这样一个解决方案所涉及的时间。
【讨论】：