我知道这已经被问过了，但我们真的很想拒绝任何提交文件的尝试，这会破坏主干中的项目。拒绝提交文件的决定是基于提交文件所属项目的构建过程的结果。我知道在预提交阶段无法同时访问存储库，但这对我们来说不是问题，因为我们的构建速度非常快，我们可以容忍任何延迟。
有什么工具可以实现我们想要的吗？请注意，有必要重新编译整个项目单元，而不仅仅是提交的单个文件。
如果不能以任何合理的方式完成，是否可以在提交后构建代码，然后在构建步骤失败的情况下立即回滚？可以配置 Hudson 或其他工具来做我们想做的事吗？
【问题讨论】：
标签： svn
即使您的构建速度很快。假设您可以在 90 秒内构建整个项目。您是否希望人们每次提交代码时都等待 90 秒？可能发生的情况是，人们只会做更少的提交，做出更大的改变，并导致更多的错误。
首先要意识到进行错误的修订并不是世界末日。如果您及早发现问题，您可以轻松地恢复更改。这里的关键是及早发现。
如果您还没有，请获取像 Jenkins 这样的持续集成系统。每当有人提交代码更改时，Jenkins 都会进行构建。如果构建的速度与您声称的一样快，那么当更改破坏构建时，您将在几分钟内收到通知。如果您愿意，您甚至可以让 Jenkins 恢复更改。我们的理念是开发人员有 10 分钟的时间来解决问题，或者恢复他们的更改。然后，我们把它们放在栅栏里，用腐烂的西红柿剥皮。 （实际上，HR 不会让我们这样做的。）
其次，设置易于遵循的标准，使开发人员能够确保他们的更改能够奏效。我们有一些基本的：
这让我可以轻松地在我们的 Jenkins 服务器上设置构建。而且，更重要的是，它使开发人员可以轻松地使用 Jenkins 将用于构建的相同构建系统。如果他们可以构建它，Jenkins 就可以构建它。
接下来，您必须改变您的开发文化。破坏构建是不好的。一旦完成，Jenkins 将公开羞辱任何破坏构建的开发人员。我看到的一家商店设置了红绿灯。如果 Jenkins 构建失败，那些灯就会变成红色。发生这种情况时，这是一件大事。经理们出来了，想知道发生了什么事。当我在那里时，那些灯从未变红。
当然，能够运行构建是软件的第一步。这是一个小小的婴儿步骤 - 甚至可能是爬行。不，甚至不是，这是一个六个月大的婴儿第一次爬行的版本。如果损坏的构建是您所在位置的主要问题，那么您将遇到非常严重的问题。
除了确保一切都可以编译之外，下一步是确保代码遵循编码标准并且代码没有做一些可能不好的事情。在 Java 世界中，它针对代码运行 Checkstyle、Findbugs 和 PMD。 Jenkins 允许我发布漂亮的图表，向我展示这些程序的结果。我们还收集所有编译警告和 JavaDoc 错误并绘制它们。如果这些进程中的任何一个发出太多警告，我们甚至可以设置 Jenkins 以使构建失败。您的代码可以编译，但由于技术不好，构建失败。
接下来是单元测试。在 Java 世界中，它是 JUnit，Jenkins 再次显示结果。如果任何 JUnit 测试失败，我们就会失败构建。如果您的基本界面不好，那么构建良好的构建并没有多大好处。
然后是代码覆盖率。我们有多少代码在进行单元测试。我们为此使用 JaCoCo。我们不会因代码覆盖率低而导致构建失败，但我们会向开发人员施加压力以提高代码覆盖率。最后，我们可以进行其他测试。我们部署并运行自动化功能和系统测试。
开发人员所做的每一项更改都会被一路轰炸到单元测试。这是我真正喜欢 Java 的地方之一，我认为 Java 开发在这方面遥遥领先。典型的 Java 构建可以在几分钟内完成。我们无法在 10 分钟内构建并运行所有单元测试的情况很少见。任何问题都会尽早发现并尽早解决。而且，所有问题都在 Jenkins 中公开展示。我们看到是谁破坏了构建或导致单元测试失败。我们看到谁有需要修复的编译器警告，或者做了一些糟糕的编码练习。
因为我为开发人员提供了 Jenkins 用于构建的相同工具集，所以他们可以很容易地看到 Jenkins 会看到什么。他们也可以运行单元测试和代码测试。他们没有理由提交导致问题多于解决问题的代码。
这就是您取得长足进步的地方：改善开发文化以关心他们在做什么，并对不良做法发出明亮的光芒。
在开发前设置障碍（例如让开发人员在每次提交后等待 90 秒以确保他们的更改生效）会引起不满，并且通常会适得其反。您不再是团队的一员，而是将每个人都视为潜在嫌疑人的build cop。相反，与开发人员合作并说服他们你想要的对他们有利。一旦他们看到这一点，他们就会与您合作，您的整个开发周期就会运行得更加顺畅。
【讨论】：
我知道一些 CI 工具可以做一个“预提交 CI”，所以变更集首先被发送到 CI 服务器进行构建，一旦它可以成功构建，它就会被提交到 SVN。
我没有亲自尝试过这样的功能，但我相信工作流程可能需要稍微改变（而不是直接提交，更改被发送到 CI 进行预提交构建）
【讨论】：
在大多数情况下，您提交到一个分支，它会被构建，如果成功，分支代码会合并到一个主干。这更适合大多数没有明确支持您所要求的 SCM 系统 - 考虑到 scm 将仅发送更改的文件，并且您需要检查构建服务器的完整列表才能工作（您并不真的想要根据之前构建留下的文件进行编译，现在是吗）。
SVN 可以在 pre-commit 钩子中愉快地执行此操作，我在此钩子中使用 perl 脚本来检查可接受的签入 cmets 并拒绝可能添加到 repo 中的不可靠文件类型，所以你没有理由不能简单地运行一个检查当前分支的脚本，然后将提交文件复制到它们的顶部，构建，然后检查构建日志。要使预提交失败，只需从脚本中返回 1（返回 0 即可通过）。
很难准确地说出您需要什么，因为我不知道您正在执行构建什么或如何执行构建，但是您的脚本需要与任何预提交挂钩脚本几乎相同。 SVN自带了几个示例，你可以看到several more on the internet。
【讨论】：