jenkins svn插件还原操作比命令行作业慢？

Question

我有三台安装了Jenkins v1.473的构建机。

我们称它们为机器A，B和C。它们都运行Windows 7 x64。 B机和C机的jenkins安装是从A机进行的。我只是将文件夹复制了过来，一切都已导入并且可以正常工作。

我们最初有一个Windows命令行作业，该作业将调用svn revert，然后对一堆文件夹进行svn更新。 之后，我们将构建我们的项目。 平均运行时间约为10分钟。 命令行工具的SVN版本在所有3台计算机上均为1.7（带有tortoisesvn）

由于我们使用的是命令行svn命令，因此在发送作业完成电子邮件时我们无权访问$ CHANGES，因此我们切换到了Jenkins svn插件。 首先在机器B和C上进行了切换，确认切换正常后，我们对机器A进行了相同的更改。插件版本为1.50。

检出策略设置为“ 在更新前尽可能使用'svn更新'，'svn恢复' ”。 存储库浏览器设置为“自动”。

在Jenkins->配置下，Subversion工作区版本设置为1.7。 其他字段保持原样（ 排除revprop名称为空，未选中第一个变量名称之前的验证存储库URL，检查成功身份验证后更新默认Subversion凭据缓存 ）

现在，到我的问题。

机器B和C的运行时间大致相同：约10分钟。

但是，在机器A上，运行时间增加了一倍以上：现在平均为25分钟。 查看作业日志，还原部分似乎是罪魁祸首。

从svn命令行切换到插件会导致它运行速度变慢吗？ 最重要的是， 仅在一台特定机器上 ？

Answer 1

在所有机器上挖掘并测试了几个作业之后，我发现了以下内容：

• 命令行工具比其插件要快得多，这很可能是由于程序本身的速度所致（编译后的C二进制与SVNKIT用Java编写并在JVM之上运行）
• 尽管具有相似的规格，但机器A也比B和C慢得多，这很可能是因为其他应用程序和服务同时运行（B和C是近乎全新的安装，而A已经运行了较长时间，安装了更多应用程序等）

最后，我只是从更新中拆分了干净/还原部分：

• 清理/还原作业是在命令行中进行的（我相信由于文件夹的遍历，I / O太重了），因此它要尽可能快
• 然后使用该插件进行更新（并且仅更新，该插件内不执行任何还原操作）（相当快，对于几十个文件，通常不到一分钟），这使我仍然可以访问CHANGES变量。

这样，我设法以某种方式使机器A上的构建时间几乎保持不变（大约10分钟）。 但是，机器B和C的构建时间大大缩短了（通常从10分钟缩短到5分钟）