svn - 当您的 ant 构建过程在您的版本控制上出现问题时该怎么办

Question

所以我有一个不错的 Java 项目，用 Ant 构建到/dist 文件夹。
整个项目都在版本控制之下，所以我可以通过 dist 文件夹路径上的 'svn export' 来部署最新版本。
但是我的构建不断删除我的 dist 文件夹中的 .svn 文件夹及其所有依赖项，因为它在构建时清除了该文件夹，而不是仅仅覆盖。罪魁祸首是 JarBundler，它是构建我的 mac.app 包的 Ant 任务——它在重新创建之前删除了整个包的文件夹。
这显然破坏了我的 svn，因为该文件夹现在缺少所有 .svn 文件夹，因此它说它存在冲突。

有人对我如何解决这个问题有任何想法吗？我不知道如何阻止 jarbundler 删除所有内容，所以我将不得不做一些我担心的更骇人听闻的事情。我对 Ant 也很陌生，仅供引用。

Answer 1

如果您希望您的源代码控制系统成为 ，那么在源代码控制中使用 dist 可以被认为是一种好习惯。唯一引用 对全部:

开发人员

汇编程序(单元测试)

认证测试人员(您在集成平台上查询一堆 dist 并在那里执行您的非回归测试、性能测试、压力测试等)

生产发布经理
...

但是你需要有一个适当的发布过程来完成它。

在您的情况下， 构建 必须在 中单独的私有(private)目录 , 那是一个不在颠覆中的目录。当构建正常时，您 进口 如果它是正式版本，则将其导入 subversion，或者如果它是临时构建，则将其导入共享目录，这只是下一个团队需要的(从而避免将数百个构建提交到 SCM，无用空间)。

注意:在您的 SCM 中进行交付 (dist) 的主要优点是允许 依赖 项目不与您的源代码一起工作，而是直接与您的交付一起工作(这必然会在某一时刻投入生产):如果他们设法使他们的代码工作，通过编译您的交付，机会是他们自己的 dist，当与您一起部署，将起作用。
这样，其他团队访问您的交付(您的“myProject.jar”)就像他们访问他们的任何源一样:他们可以通过 SCM 读取您的 jar 的版本、日期、历史、元数据、标签和很快。

然而，对于一个小型单体(如“没有其他项目依赖它”)项目，可以说 dist(最终打包交付) 可以按需重新构建并存储在外部引用系统中 ，例如作为外部 Maven 存储库。
但是:Maven 不是 SCM 存储库，这意味着您需要签署您的 jar('MyProject-1.0.jar')，您没有历史记录，并且您需要在交付时在单独的文本文件中报告所有元数据。在该 Maven 存储库中访问该交付的任何其他项目都需要根据您的版本命名约定调整其脚本和类路径。
另外，Maven 是您开发架构中的另一个存储库。只要您可以将存储库的数量保持在最低限度('1' ;))，那就更好了。