我的一些同事确信，将构建工件提交到 subversion 存储库是个好主意。论点是，通过这种方式，在测试机器上安装和更新很容易 - 只需“svn up”！
我敢肯定，有反对这种不良做法的有力论据，但我能想到的只是蹩脚的论据，比如“它占用了更多的空间”。不这样做的最好，杀手级理由是什么？我们还应该采取哪些其他方法呢？
这是针对Java代码的，如果这有所作为的话。所有内容都是从 Eclipse 编译而来的（没有自动 PDE 构建）。
当我说添加构建工件时，我的意思是提交看起来像这样：
"Added the new Whizbang feature"
M src/foo/bar/Foo.java
M bin/Foo.jar
每个代码更改都有相应的生成的 jar 文件。
在我看来，代码存储库应该只包含源代码以及编译此源代码所需的第三方库（在构建过程中，也可以使用一些依赖管理工具检索第三方库）。生成的二进制文件不应与源代码一起签入。
我认为在你的情况下，问题在于你没有适当的构建脚本。这就是为什么从源代码构建二进制文件涉及一些工作，例如启动eclipse，导入项目，调整类路径等。
如果有构建脚本，则可以使用以下命令获取二进制文件：
svn update; ant dist
我认为不签入二进制文件以及源代码的最重要原因是您的存储库的最终大小。这将导致：
另一个原因可能是：
此外，在我看来，如上所述的方法引入了很多开销。如果开发人员忘记更新相应的 jar 文件，该怎么办？
首先，Subversion（以及现在的所有其他版本）不是源代码控制管理器（我一直认为SCM意味着软件配置管理），而是版本控制系统。这意味着它们存储了对你存储在其中的内容的更改，它不必是源代码，它可以是图像文件，位图资源，配置文件（文本或xml），各种东西。构建的二进制文件不应被视为此列表的一部分的原因只有 1 个，这是因为您可以重新构建它们。
但是，想想为什么还要将已发布的二进制文件存储在那里。
首先，它是一个帮助您的系统，而不是告诉您应该如何构建应用程序。让计算机为你工作，而不是反对你。因此，如果存储二进制文件占用空间怎么办 - 您拥有数百千兆字节的磁盘空间和超快速的网络。将二进制对象存储在那里已经不是什么大不了的事情了（而十年前它可能是一个问题 - 这也许就是为什么人们认为SCM中的二进制文件是一种不好的做法）。
其次，作为开发人员，您可能习惯于使用系统来重建应用程序的任何版本，但可能使用它的其他人（例如qa，test，support）可能不会。这意味着你需要一个替代系统来存储二进制文件，实际上，你已经有了这样一个系统，它是你的SCM！利用它。
第三，您假设您可以从源代码重建。显然，您将所有源代码存储在那里，但您没有存储编译器，库，sdk以及所需的所有其他依赖项。当有人走过来问我“你能为我构建我们2年前发布的版本吗，客户对那个版本有问题”时会发生什么。2年是永恒的，你甚至有你当时使用的编译器吗？当您签出所有源代码后发现新更新的 sdk 与您的源代码不兼容并失败并出现错误时，会发生什么情况？您是否擦除了开发框并重新安装了所有依赖项以构建此应用程序？你还记得所有的依赖关系是什么吗？！
最后一点是最重要的一点，为了节省几k的磁盘空间，你可能会花费自己几天甚至几周的痛苦。（Sod定律还说，无论你需要重建哪个应用程序，都将是最晦涩难懂的，难以设置的依赖关系的应用程序，你曾经很高兴摆脱）
因此，将二进制文件存储在SCM中，不要担心琐事。
PS.我们将每个项目的所有二进制文件都放在它们自己的“release”目录中，然后当我们想要更新机器时，我们使用一个特殊的“setup”项目，该项目仅由svn：externals组成。导出安装项目，您就完成了，因为它提取了正确的内容并将其放入正确的目录结构中。
