参数再次将二进制文件检入SCM

我在一家主要构建Java应用程序的公司工作，我试图说服所有人停止将二进制文件（依赖项和最终产品）检入SCM。

他们知道这是一个不好的做法，但是他们认为“有效”，即使很多人都了解Maven和除Ant之外的其他构建工具，这也不是真正的问题。经理和程序员（大约50人）都准备好听取任何反对意见，甚至承认这是对备份空间的浪费，但是我要说服自己，因为习惯的改变会涉及很多工作。您使用什么论据来支持变更？

编辑：好的，区分几乎不变的文件（如依赖项）和生成的文件是有意义的。即使这样，我还是有理由反对后者。

存储空间很便宜，因此对于为什么应该或不应该签入文件，这并不是一个令人信服的论点。

相反，您可以诉诸SCM。SCM跟踪的每个文件都表示需要管理团队正在执行的并行，分布式更改。在两个团队成员尝试更改同一文件之前，这些都不是很明显。解决这些更改是SCM真正的目的，可以防止意外覆盖另一位开发人员的工作，并希望可以自动化这些更改的合并过程。

合并二进制文件通常是一个真正的挑战，因为通用合并工具没有明智的方法来猜测合并的二进制文件应如何工作。除非经过专门设计以识别特定文件类型，否则它对文件中的索引或偏移指针的工作方式知之甚少。

这意味着由开发人员手动合并二进制文件，然后告诉SCM该文件已被如此合并。由于是开发人员执行的，因此合并可能不会真正涵盖之前签入的所有更改，并且由于文件是二进制文件，因此没有自动的方法来验证合并。

对于真正代表项目来源的二进制格式（例如艺术品），这是一个不幸的步骤，但却是必需的步骤。但是，构建输出不是源。无需合并它们，因为可以合并源，并且可以重新生成生成的构建输出。跟踪和管理这些更改是100％的浪费。它浪费了SCM的资源，虽然不是很多，但也浪费了开发人员克服虚假合并失败的时间。开发人员时间非常昂贵，任何浪费时间的都是癌症。

另一方面，在特定情况下，应该将构建输出存档。可能已经无限期地保留了已经交付或部署的项目的任何版本。由于客户将拥有确切的版本，因此拥有客户遇到问题的实际版本的逐字节副本可以使支持该客户变得容易得多。

该备份可能不应该与源代码位于同一存储库中，因为它们通常遵循不同的时间表，并且具有基本不同的结构。

依赖项，即使是二进制形式的，都应该被签入，以便当其他人拉下项目时，它就可以正常工作。主要关注的不是文件的类型，而是文件的创建方式。我使用的经验法则是，如果可以使用其他文件生成该文件，则不会将其检入-这意味着自动生成的文档，我创建的二进制文件，等等。

使用SCM的主要优点之一是您可以从过去的任何时间重建系统。因此，将最终版本存储在SCM中是没有意义的，因为您只需签出修订号并进行构建即可。

您提到依赖项...应该设置您的SCM，以便您可以对新计算机（具有开发环境）进行干净签出，按构建，然后就可以构建系统而无需安装其他任何东西。因此，在您的SCM中保留二进制依赖性是一个好主意。图书馆很少变化，因此不会占用太多空间。

几乎没有人这样做。

似乎同时包含源文件和目标文件是多余的（显然需要源文件）。除了不必要之外，目标文件可能会占用大量空间。如果您的公司使用的是分布式SCM（Git，Hg，Bzr），则必须在所有开发人员之间复制并存储这些二进制文件。