在您的版本控制上使用ant构建过程时该怎么做

Question

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

任何人对我如何解决这个问题都有任何想法？我无法弄清楚如何阻止jarbundler删除所有东西，所以我不得不做一些我更害怕的hacky。我也是Ant的新手，仅供参考。

Answer 1

如果您希望源控制系统成为所有人的 唯一参考 ，那么将源控制中的dist 可以视为良好做法：

• 开发
• 汇编程序（单元测试）
• 认证测试人员（您在集成平台上查询一堆dist，并在那里进行非回归测试，性能测试，压力测试等）
• 生产发布经理 ...

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

在您的情况下，版本必须位于 单独的私人目录 中，这是一个不在subversion中的目录。当构建正常时，如果它是官方版本，则 导入 进入subversion，或者如果它是官方版本，则将其导入到共享目录中一个临时构建，只需要下一个团队（因此避免将数百个构建提交到SCM中，无空间使用空间）。

注意：在SCM中进行交付（dist）的主要优点是允许 依赖 项目不与您的来源合作，而是直接与您的交付合作（这必然会在某个时刻进入生产阶段）：如果他们设法使他们的代码工作，通过编译你的交付，他们自己的dist，当与你一起部署时，可能会工作。
这样，其他团队在访问他们的任何来源时访问您的交付（您的'myProject.jar'）：他们可以通过SCM读取您的jar版本，日期，历史，元数据，标签和等等。

然而，对于一个小的整体（如“没有其他项目依赖它”）项目，可以认为dist（最终打包交付）可以根据需要重新构建并存储在外部参考系统，作为外部Maven存储库。例如 但是：Maven不是SCM存储库，这意味着您需要在jar上签名（'MyProject-1.0.jar'），您没有历史记录，并且您需要在交付时在单独的文本文件中报告所有元数据。在该Maven仓库中访问该交付的任何其他项目都需要根据您的版本命名约定调整其脚本和类路径。
此外，Maven是您的开发体系结构中的另一个存储库。每当你能将回购数量保持在最低值（'1';）时，就更好了。

Answer 2

简单。不要检入/ dist in版本控制。

版本控制真的不应该有任何生成的代码/二进制文件/ jar / what-have-you。

Answer 3

可能我在这里遗漏了一些东西，但你为什么要在源代码控制系统中检查你的内置产品？一般来说，这不是一种好的做法。

如果您确实要签入构建产品，请将它们复制到其他位置（可能是一个名为“预构建”的目录），然后从那里检查它们。

编辑添加：您不应该这样做的原因是，在给定当前源的情况下，您应该能够使用单个构建命令重新创建分发。

Answer 4

好的，谢谢大家。 我现在明白为什么在哲学上保持SCM的构建是一个好主意，并将在未来考虑到这一点。 然而，实际上，在这种情况下，我是这个短期（4周）项目的唯一开发人员。我正在使用svn 轻松通过低速连接更新公共网络服务器上的发布版本，以便差异更新至关重要。 由于没有人建议更新远程部署版本的简单替代方法，我想出了这个hacky hack来避免我的问题：

说我的版本化构建文件夹是/ dist。好吧，我告诉我的构建脚本构建到/ dist-tmp，然后递归复制/ dist-tmp中所有文件在/ dist的顶部，然后最后删除/ dist-tmp。

我的Ant构建脚本中有一些额外的行，效果很好。

下一次，生病确保部署主机不是Windows，然后一个简单的rsync脚本就可以了，然后我可以将生成器从SCM中移除。

@VonC得到了哲学最佳解释的答案。

Answer 5

我同意将构建的产品放入SVN并不是一个好习惯。

话虽如此，如果你有一些要求做到这一点，你无法绕过，你可以使用一个更现代的版本控制系统，如Git，Bazaar和Darcs（还有其他，但我已经使用这三个）。

所有这三个只将版本控制元数据放在根目录中，所以子文件夹中没有元数据，所以我认为你不会有这个问题......