Working copies created by the Jenkins Subversion plugin are very slow to work with. I think that the problem is that the plugin and its Subversion libraries don't maintain enough precision in file timestamps.

Details:

One of the steps in our build process runs svnversion on a large working copy. We noticed that this operation took over 30 times longer in a working copy created by Jenkins' Subversion plugin, compared to a working copy checked out in the standard svn command-line (CLI) client.

I ran strace svnversion (with the appropriate arguments) from the Jenkins working copy and the CLI working copy and noticed that, for files in the CLI working copy, svnversion did an lstat64 and then proceeded with the next file. For files in Jenkins' working copy, svnversion appeared to do an lstat64 three times then open both the file and its .svn/pristine original version and compare their contents.

I inspected the .svn/wc.db and noticed that almost every entry in nodes table for the Jenkins working copy has no sub-second precision in the last_mod_time column. (I.e., last_mod_time % 1000000 is 0 for nearly every entry.) In the CLI working copy, the sub-second timestamps in the last_mod_time column match the files' modified timestamps in the filesystem down to the microsecond. I suspect that svnversion detects that the timestamps match down to the microsecond and skips comparing their contents. Because the Jenkins working copy's wc.db doesn't have this sub-second precision, svnversion has to compare file contents, which can be very, very slow.

I'm unclear on the relationship between the Subversion plugin and any upstream libraries, so if this should be reported to an upstream Subversion implementation, please let me know, and I'll report it there. Thanks.