I have three build machines with Jenkins v1.473 installed.
Let's call them machine A, B and C. All are running Windows 7 x64. Machine B and C jenkins installation was carried over from machine A. I simply copied the folder over and everything was imported and works fine.
We initially had a Windows command line job that would call svn revert and then, svn update on a bunch of folders. After that, we would build our project. The average running time was about 10 mins. SVN version of the command line tools is 1.7 on all 3 machines (with tortoisesvn)
Since we were using command line svn commands, we didn't have access to $CHANGES when sending the job completion email, so we switched to the Jenkins svn plugin. The switch was made on machine B and C first and after confirming it was working fine, we applied the same changes to machine A. The plugin version is 1.50.
Check-out Strategy is set to "Use 'svn update' as much as possible, with 'svn revert' before update". Repository browser is set to Auto.
Under Jenkins->Configuration, Subversion Workspace Version is set to 1.7. The other fields are left as-is (Exclusion revprop name is empty, Validate repository URLs up to the first variable name is unchecked, Update default Subversion credentials cache after successful authentication is checked)
Now, onto my issue.
The running time on machine B and C stayed about the same: about 10 mins.
However, on machine A, running time has more than doubled: it now averages 25 mins. Looking at the job log, the revert part seems to be the culprit.
Is there a reason switching from svn command line to the plugin would make it run slower ? On top of that, on one particular machine only ?