我有三台安装了Jenkins v1.473的构建机器。
让我们称它们为机器A，B和C.所有都运行Windows 7 x64。 机器B和C jenkins安装从机器A继承。我只是将文件夹复制过来，所有东西都被导入并且工作正常。
我们最初有一个Windows命令行作业，它会调用svn revert，然后在一堆文件夹上进行svn update。在那之后，我们将构建我们的项目。平均运行时间约为10分钟。所有3台机器（带有tortoisesvn）的命令行工具的SVN版本为1.7
由于我们使用命令行svn命令，因此我们在发送作业完成电子邮件时无法访问$ CHANGES，因此我们切换到了Jenkins svn插件。 交换机首先在机器B和C上进行，在确认它工作正常后，我们对机器A应用了相同的更改。插件版本为1.50。
结帐策略设置为＆＃34; 使用＆＃39; svn update＆＃39;尽可能地使用“恢复”＃39;更新前＆＃34;。 存储库浏览器设置为自动。
在Jenkins-＆gt;配置下，Subversion工作区版本设置为1.7。 其他字段保持原样（排除revprop名称为空，验证存储库URL到第一个变量名称未选中，更新默认的Subversion凭据缓存后成功验证已选中）
现在，关于我的问题。
机器B和C的运行时间大致相同：约10分钟。
然而，在机器A上，运行时间增加了一倍以上：现在平均为25分钟。 查看工作日志，恢复部分似乎是罪魁祸首。
有没有理由从svn命令行切换到插件会让它运行得更慢？最重要的是，仅在一台特定的机器上？
答案 0 :(得分：1)
在所有机器上挖掘和测试多个工作后，我发现了这个：
最后，我只是将清理/还原部分从更新中分离出来：
有了这个，我以某种方式设法使机器A的建造时间几乎保持不变（大约10分钟）。 然而，机器B和C的建造时间大大改善（一般从10分钟到5分钟）