我的一些同事坚信将构建产物提交到Subversion仓库是一个好主意。他们认为这样做可以轻松地在测试机器上安装和更新，只需 "svn up"！
我确信有很多反对这种不良做法的有力理由，但我能想到的都是一些无聊的理由，比如 "它占用更多的空间"。不做这件事的最佳和最有说服力的理由是什么？还有其他应该采取的方法吗？
如果这是针对Java代码的话，这会有所区别。所有的代码都是从Eclipse编译（没有自动化的PDE构建）。
当我说添加构建产物时，我的意思是提交会像这样：
"Added the new Whizbang feature"
M src/foo/bar/Foo.java
M bin/Foo.jar
每次代码更改都会生成相应的 jar 文件。
svn update; ant dist
我认为不将二进制文件与源代码一起提交的最重要原因是导致存储库大小增加。这样会引起以下问题：
另一个原因可能是：
此外，你上述的方法在我看来还带来了很多额外的开销。如果开发人员忘记更新相应的 jar 文件会怎么样呢？
像Hudson这样的持续集成服务器可以存档构建产物。虽然这并不能帮助你解决“为什么不”的问题，但至少它是一种替代方案。
我确定有很多有力的反对意见针对这种不良做法。
你错误地认为将“build artifacts”提交到版本控制是一个不好的主意（除非你错误地阐述了你的问题）。事实并非如此。
在版本控制中保存你所谓的“build artifacts”是可以的，而且非常重要。你还应该保存编译器和其他用于将源文件转换为成品的工具。
从现在起五年后，你肯定会使用不同的编译器和不同的构建环境，这些环境可能无法编译今天的版本，出于任何原因。对一个旧版本进行修复一个小bug可能会变成噩梦，需要将旧软件移植到当前编译器和构建工具中，只是为了重新编译一个有一行更改的源文件。
因此，你没有理由害怕将“build artifacts”存储在版本控制中。你可以将它们分开存储。
我建议将它们分开，例如：
ProjectName
|--- /trunk
| |--- /build
| | |--- /bin <-- compilers go here
| | |--- /lib <-- libraries (*.dll, *.jar) go here
| | '--- /object <-- object files (*.class, *.jar) go here
| '--- /source <-- sources (*.java) go here
| |--- package1 <-- sources (*.java) go here
| |--- package2 <-- sources (*.java) go here
根据我的经验，将Jars存储在SVN中可能会导致混乱。
我认为最好将Jar文件保存在像Nexus这样的Maven仓库中。
这也有优点，您可以使用像Maven或Ivy这样的依赖管理工具。
二进制文件，尤其是自己的二进制文件，但也包括第三方的，不应该存储在像 SVN 这样的源代码控制工具中。
理想情况下，你应该有一个构建脚本来构建自己的二进制文件（可以使用许多优秀的自动构建工具之一，这些工具可以直接从 SVN 检查源代码并进行自动化）。
对于第三方二进制文件，您需要像 Maven2 这样的依赖管理工具。然后，您可以设置一个本地 Maven 存储库来处理所有第三方二进制文件（或者只依赖公共的）。本地存储库还可以管理您自己的二进制文件。
把二进制文件放在代码仓库的主干或分支上绝对是累赘。除了像你提到的那样占用空间，它还会导致源代码与二进制文件之间的不一致性。当你提到修订版本1234时，你不希望疑惑这是否意味着“来自修订版本1234的源代码构建”还是“修订版本1234中的二进制文件”。避免不一致性的相同规则也适用于自动生成的代码。你不应该将可以由构建生成的内容进行版本控制。
另一方面，我更或多或少同意将二进制文件放在标签中。这样其他项目就可以通过svn:externals使用其他项目的二进制文件，而无需构建所有这些依赖项。它还使测试人员可以轻松地在不需要完整构建环境的情况下在不同的标签之间切换。
要将二进制文件放在标签中，您可以使用以下过程：
svn copy myWorkingCopyFolder myTagURL我们有一个tagbuild脚本来半自动化步骤3和4。
一个好的理由是快速在新机器上运行可执行文件。特别是如果构建环境需要花费一段时间来设置。(加载编译器、第三方库和工具等)
检查重要二进制文件违反了源代码/SVN的使用原则，即源代码控制中的文件应具有“差异”的有意义属性。
今天的源文件与昨天的源文件有着有意义的不同之处；差异将产生一组变化，这些变化对人类读者有意义。今天办公室前面的照片与昨天的相同位置的照片没有任何意义的差别。
因为像图像这样的东西没有差异的概念，所以你为什么要将它们存储在一个存在于记录和存储文件之间“差异”的系统中呢？
基于版本的存储是关于存储文件更改历史的。 (例如) JPEG 文件中没有有意义的更改历史。这些文件在目录中同样可以完美地进行存储。
更实际的是，将大型文件 - 构建输出文件 - 存储在 SVN 中会使检出速度变慢。滥用 SVN 作为广义二进制存储库的可能性是存在的。一开始似乎没什么问题——因为没有太多的二进制文件。当然，随着时间的推移，文件数量也会增加。我见过需要几个小时来检出的模块。
最好将大型关联的二进制文件（和输出文件）存储在一个目录结构中，并从构建过程中引用它们。