Svn 你对版本控制有多深？

“磁盘”便宜的理论最近有点失控了。版本控制有一些强大的方面，使我们能够通过几个引导文件和一个简单的命令来引导新开发人员完成工具链

最近对系统的升级促使人们要求存储内置的二进制文件。随后，请求对整个虚拟化构建系统进行版本设置。添加到顶部的每一层都在存储库之间创建了重要的关系，管理它需要良好的基础设计

工具链的存储带来了即时的好处，而构建的二进制文件的存储带来了即时的责任。不幸的是，Git在处理大型二进制文件时存在一些基本问题

---

以正确的方式使用VC的界限在哪里？什么时候开始研究更合适的解决方案？

我认为这里有一个操作顺序：

如果他们需要存储文件，请使用文件系统

如果他们需要跟踪更改，请使用版本控制

如果他们需要跟踪与数据的关系，请使用数据库

---

需求越复杂，解决方案就越复杂。但对于那些想要更复杂的解决方案的人来说，纪律是必要的；在这个不确定的时代，我们必须避免浪费时间。

我坚持经典的答案，即存储构建最终产品所需的任何东西。不需要二进制文件和中间文件，但包含构建中使用的所有脚本

---

我使用我的git repos作为备份，在至少两个地方存储裸克隆，因此我尽量不遗漏构建所需的任何内容，但我不介意存储任何暂时的内容。

没有它就无法重新创建的版本控制。因此，工具链不能轻易地重新创建-版本控制是有意义的。有了版本控制下的工具链（和源代码），就不需要对构建产品进行归档——或者至少在构建测试完成后不需要归档。

您可能不应该将“整个虚拟化构建系统”存储为一个巨大的二进制文件。如果要对应用程序进行版本设置，则需要对源代码进行版本设置，而不是对已编译的二进制文件进行版本设置

许多商店所做的是将重新创建构建服务器的步骤存储在版本控制中。然后，您需要一个固定的映像（一个库存，开箱即用的操作系统安装），再加上少量的文件（要在上面安装什么，以及如何安装）。有些地方甚至让服务器在每次部署/重新启动时，在干净的操作系统上从源代码重新构建应用程序

将操作系统映像本身作为一个巨大的二进制文件进行版本控制几乎没有那么有用。你不能分支。你不能合并。你不能区分，有什么意义？如果你的风投可以做二进制差异，你可能会节省空间，但这可能需要大量的CPU和内存，如果他们在“磁盘很便宜”的狂欢中，那么没有理由仅仅为了节省磁盘空间而让生活痛苦

---

在VC中存储安装脚本/库并根据需要重建VM映像，或者只在普通文件中存储VM映像。我看不出将图像放在VCS中有任何意义。

常识，而不是繁琐，应该指导您如何控制和配置工具链。如果您有标准硬件并且经常添加开发人员，那么将构建的工具链存储为图像是有意义的；但是这些图像不需要进行版本控制。如果你有50名开发人员，你的工具链配置管理系统将减少开销；如果您有5个开发人员，那么开销会更大--需要学习另一个系统

那么，Git是否妨碍了你想做的事情？或者你收到请求是因为用户试图说你应该让你的系统更复杂，因为你可以这样做

如果您的构建工具已经成熟，那么构建日期可能足以确定所使用工具的版本。您可以让构建脚本编写构建工具及其版本的文本文件，类似于依赖项列表

---

如果您使用的是快速变化的内部工具，或者是处于积极开发中的项目的alpha/beta版本，那么将构建工具置于版本控制之下是一个很好的理由——但这将解决错误的问题。为什么要使用不稳定的工具链进行构建

对于一种非常极端的方法，请查看

发件人：

维斯塔方法基于以下基础：

• 所有源和工具的不可变、永久、版本化存储。不像 ClearCASE，Vesta使用明确的版本号而不是视图

• 完整的、基于源代码的配置描述。我们所说的完整，是指 这些描述命名了对生成有贡献的所有元素。计算环境的各个方面，包括工具、库、头文件、， 和环境变量，完全由灶神星描述和控制。通过 基于源代码，我们的意思是配置描述指定如何构建 仅使用不可变源（即非派生文件）的从头开始的系统。 描述本身是版本化的、不可变的源，其 意义是不变的；特定的顶级描述总是使用相同的源代码精确地描述相同的构建，即使在新版本的 已创建源和描述

• 自动派生文件管理。派生文件的存储和命名 由Vesta存储库自动管理，从而简化 构建多个版本或构建多个目标平台的负担

• 所有构建工作的站点范围缓存。Vesta具有一个共享的站点范围缓存 开发人员可以从彼此的构建中获益

• 自动相关性检测。Vesta builder动态检测并 记录所有依赖项，因此任何依赖项都不能被人为错误忽略。