所以我有一个不错的 Java 项目，用 Ant 构建到 /dist 文件夹。
整个项目都在版本控制之下，所以我可以通过 dist 文件夹路径上的 'svn export' 部署最新版本。
但是我的构建不断删除我的 dist 文件夹中的 .svn 文件夹及其所有依赖项，因为它在构建时清除了该文件夹，而不是仅仅覆盖。罪魁祸首是 JarBundler，它是构建我的 mac.app 包的 Ant 任务 - 它在重新创建之前删除了整个包的文件夹。
这显然破坏了我的 svn，因为该文件夹现在缺少所有 .svn 文件夹，因此它说它存在冲突。
有人对我如何解决这个问题有任何想法吗？我不知道如何阻止 jarbundler 删除所有内容，所以我将不得不做一些我担心的更骇人听闻的事情。我对 Ant 也很陌生，仅供参考。
如果您希望您的源代码控制系统成为所有人的唯一参考，那么在源代码控制中使用 dist可以被认为是一种好的做法：
但是你需要有一个适当的发布过程来完成它。
在您的情况下，构建必须位于单独的私有目录中，即不在颠覆中的目录。当构建正常时，如果是正式版本，则将其导入subversion，如果是临时构建，则将其导入共享目录，下一个团队需要（从而避免将数百个构建提交到 SCM，无用空间）。
注意：在 SCM 中进行交付（dist）的主要优点是允许依赖项目不与您的源一起工作，而是直接与您的交付一起工作（这必然会在某个时间点或另一个时间点投入生产）：如果他们管理为了使他们的代码工作，通过与您的交付一起编译，他们自己的 dist 很可能在与您一起部署时可以工作。
这样，其他团队访问您的交付（您的“myProject.jar”）就像他们访问他们的任何资源一样：他们可以通过 SCM 读取您的 jar 的版本、日期、历史、元数据、标签和很快。
然而，对于一个小型单体（如“没有其他项目依赖它”）项目，可以说 dist （最终打包交付）可以按需重新构建并存储在外部引用系统中，作为外部例如 Maven 存储库。
但是：Maven 不是 SCM 存储库，这意味着您需要签署您的 jar（'MyProject-1.0.jar'），您没有历史记录，并且您需要在交付时在单独的文本文件中报告所有元数据。在该 Maven 存储库中访问该交付的任何其他项目都需要根据您的版本命名约定调整其脚本和类路径。
另外，Maven 是您开发架构中的另一个存储库。只要您可以将存储库的数量保持在最低限度（'1' ;)），那就更好了。
简单的。不要将 /dist 签入到版本控制中。
版本控制真的不应该有任何生成的代码/二进制文件/jars/what-have-you。
可能我在这里遗漏了一些东西，但是为什么您将构建的产品检查到您的源代码控制系统中？一般来说，这不被认为是好的做法。
如果您确实想签入构建产品，请将它们复制到其他地方（可能是一个名为“pre-built”的目录），然后从那里签入。
编辑添加：您不需要这样做的原因是，给定当前源，您应该能够使用单个构建命令重新创建分发。
好的，谢谢大家。我现在明白了为什么从哲学上讲，将构建保持在 SCM 之外是一个好主意，并将在未来牢记这一点。然而，实际上，在这种情况下，我是这个短暂（4 周）项目的唯一开发人员。我正在使用 svn通过低速连接轻松更新公共网络服务器上的发布版本，因此差异更新是必不可少的。由于没有人提出更新远程部署构建的简单替代方案，因此我想出了这个 hacky hack 来避免我的问题：
假设我的版本化构建文件夹是 /dist。好吧，我告诉我的构建脚本构建到 /dist-tmp，然后递归地将 /dist-tmp 中的所有文件复制到 /dist 的顶部，最后删除 /dist-tmp。
这是我的 Ant 构建脚本中的一些额外行，并且效果很好。
不过，下一次，请确保部署主机不是 windows，然后一个简单的 rsync 脚本就可以解决问题，然后我可以将构建留在 SCM 之外。
@VonC 得到了最佳哲学解释的答案。
我同意将内置产品放入 SVN 不是很好的做法。
话虽如此，如果您有一些无法解决的要求，您可以使用更现代的版本控制系统之一，例如 Git、Bazaar 和 Darcs（还有其他的，但我使用了这三个）。
所有这三个都只将版本控制元数据放在根目录中，所以子文件夹中没有元数据，所以我认为你不会有这个问题......