-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
linux redhat 2.6.18-238.el5
-
Powered by SuggestiMate
jenkins throws :
ERROR: Failed to update https://XXXXXXX
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/svn/playspan/!svn/vcc/default': 500 Internal Server Error
on attempt to run build.
on svn server side in the error log:
" Could not access revision times. 500, #0"
I think what happened was:
when build is requested, svnkit is trying to run svn log on the svn server by runnint it between two time stamps - previous build and current time. sometimes either dates were not recorded on svn server or the current dated obtained on the jenkins server is running ahead of svn server and, I think, this causes the problem.
my suggestion:
do not use timestamp at all
instead run log (or svn diff) between two revision numbers, which are always present on svn server.
2. I think running svn log on remote svn server is not very efficient.
I think, would be better:
1. when build is requested, capture current revision on the working space.
2. run svn update
3. capture the revision
4. run log or diff locally between two revisions.
this way, jenkins will communicate to svn server just once instead of multiple times.
[JENKINS-17431] 500 Internal Server Error on attempt to run a build
Why would a timestamp not be recorded on the svn server? IMO that's not possible: a revision has always also a timestamp.
Can you give the full stacktrace of the error?
thank you for responding. i see it has been changed to major from blocker... i think it should be blocker, as this problem prevents build to run... and our build engineer after we got this 500 response, ran build manually with mvn command... and build was fine. so, this tells me, that there is nothing wrong with the code, nor with subversion.
and, please, let me make my point clearer. I saw the plugin code - it is very interesting and neat... however, I think in order to make a decision whether or not to run the build - you don't need to obtain the time and run svn command to see if there is any difference in the code between timestamps. 1. the difference can be found in easier way. svn -r <revision-number> is one of them.
2. the timestamp itself... is never reliable thing, in my opinion. there so many things affecting it, so you simply cannot rely on it. name just a few, would be: the precision you are retriving timestamp and other computer is different. the time between machines is NEVER the same. even ntpd server is synchronizing it, however, it runs periodically, plus, if nptd finds significant difference, it won't adjust time fully, being afraid to break system dependant thing, so will do it gracefuly... while your program obtains time...
i can list some other things affecting timestamp... if you want to...
so, my main point is do not use timestamp to calculate difference. i think would be easier and faster to calculate size of checked out space before svn update and after.
...and I am not saying that svn response on it is completely valid... 500 error actually perhaps not the best answer... but this is just a matter of how developer typed in the text in response to the error. and according to what I see in subversion code, and how I understand it - subversion could not find such timestamp in its db, so... responded... why it could not find it? could be because this time doesn't exist yet (like i said... time on the machine sending the request is running a little bit ahead of svn server), or it is being malformed somehow, or it is something else... it is not easy to process timestamps...
anyway, please see below the errors:
ERROR: Failed to update https://svn.xxx.com:xxx/svn/XXXXXXXXXXXXXXX
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/svn/xxxxx/!XXX/default': 500 Internal Server Error (https://xxxx.com:xxx)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:207)
at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:475)
at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:464)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:486)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:143)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: svn: E175002: REPORT of '/svn/xxxxxx/default': 500 Internal Server Error (https://xxxxx.com:xxx)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:452)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:460)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:325)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:200)
... 28 more
ERROR: Subversion update failed
hudson.util.IOException2: remote file operation failed: /svn/xxxxxxxxx
at hudson.remoting.Channel@6b1701fd:xxxxxxxx
at hudson.FilePath.act(FilePath.java:861)
at hudson.FilePath.act(FilePath.java:838)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1364)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:670)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:575)
at hudson.model.Run.execute(Run.java:1575)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: java.io.IOException
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:184)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: hudson.scm.subversion.UpdaterException: failed to perform svn update
... 15 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/xxxxxx/default': 500 Internal Server Error (https://xxxx.com:xxxxx)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:207)
at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:475)
at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:464)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:486)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:143)
... 14 more
Caused by: svn: E175002: REPORT of '/xxxx': 500 Internal Server Error (https://xxxx.com:xxx)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:452)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:460)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:325)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:200)
... 28 more
just FYI:
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html
Since the timestamp of a revision is stored as an unversioned, modifiable property of the revision (see the section called “Properties”), revision timestamps can be changed to represent complete falsifications of true chronology, or even removed altogether. Subversion's ability to correctly convert revision dates into real revision numbers depends on revision datestamps maintaining a sequential ordering—the younger the revision, the younger its timestamp. If this ordering isn't maintained, you will likely find that trying to use dates to specify revision ranges in your repository doesn't always return the data you might have expected.
...and this... (on the same page)
Is Subversion a Day Early?
If you specify a single date as a revision without specifying a time of day (for example 2006-11-27), you may think that Subversion should give you the last revision that took place on the 27th of November. Instead, you'll get back a revision from the 26th, or even earlier. Remember that Subversion will find the most recent revision of the repository as of the date you give. If you give a date without a timestamp, such as 2006-11-27, Subversion assumes a time of 00:00:00, so looking for the most recent revision won't return anything on the 27th.
If you want to include the 27th in your search, you can either specify the 27th with the time (
{"2006-11-27 23:59"}), or just specify the next day (
{2006-11-28}).
so, I believe, using time/date stamps is not the best and most reliable approach to make a decision for a build nor it will correctly update your working space.
regards,
Slava
Okay the 2nd paragraph is no big deal - it just says that the time defaults to 0 hour if you don't specify it.
About the 1st paragraph: so what is the point you want to make? That if you really want to mess with the timestamp, you can.
Yeah okay, you may, but I don't think that's something 'sane' to do.
Let me tell you how I see it:
- Jenkins has been using timestamps in the svn-plugin for a very long time. This has worked well for the big majority of users. There's an occasional bug report about 'wrong updates' which almost always has something to do with out-of-sync clocks and so easily resolved.
- for some reason it is not working for you. Maybe because you messed with the timestamps. That's IMO a problem with your configuration and no bug in the svn-plugin
- if you have a better idea on how to handle updates in the svn-plugin, feel free to post your concrete idea (loose ideas to work with revisions instead of timestamps have already been posted before. They're IMHO no big help) - i.e. as a Github pull request. However, I think that the danger of introducing backwards incompatible changes by this is IMO very very big. So we would need to introduce it as an optional setting. Which would in turn bring up the question why we need this setting, when the plugin is working very well in the vast majority of environments ...
BTW: you may also want to experiment with the @HEAD setting in the repository URLs
Hello,
First of all… I am not your enemy… so words about loose ideas to work with revision instead of timestamps… “you messed up with timestamps” … perhaps not so nice…
Anyway…
1. I think you are mistaken. What this lines are saying is: when subversion cannot fully read and understand the timestamp, but understands it partially, it assumes that time is 00:00 (midnight) of that day. You, in your request may not mean it, right?
2. I did not delete any timestamps. I checked all the repos I am administering several thousand revisions back – all timestamps are there. Yes, they can be changed. I personally never did it for any single timestamp in any repo I am administering. Users…. might however.
3. I made my point clear many times already – timestamp are difficult to deal with and they cannot be reliable in making decision whether or not to run build. Besides, it is not efficient to use timestamp to search repo if any revision were made for this particular place in repo between these two timestamps – too much work… revisions are better and more clear defined properties to deal with, so I am proposing to make changes in the code and get rid of this approach with timestamps and use revision numbers instead.
Regards,
Slava
(I know that you're not my 'enemy'. If I wrote some words which you consider insulting, I'm sorry for this)
Re 1: No, that's definitely not what the 2nd paragraph says.
Re 2: Okay, so someone in your organisation may have messed with the timestamps. Or not. After all I'm not really convinced that timestamps are your problem. At least I didn't see any conclusive hint in the stacktrace of it.
Re 3: what I wanted to say with 'loose ideas': inconcrete ideas ('lets use revisions instead of timestamps') have been expressed before (just search JIRA for duplicates). It doesn't help if you say it again. Please concrete your idea by a pull request, if you think the change is really necessary (I don't think so)
ok.
sorry... I don't know your name...
alright. let's assume it is not a svnkit problem.
then explain to me please, how come, when we get this 500 error (which are getting from time to time, and when it is happening it is always when svnkit is trying to update working space with timestamp), and when build engineer by suggestion, runs build manually using mvn, this build goes just fine.
so, it means svn itself is ok. code is fine... and only third party is left here... svnkit.
or perhaps you another explanation?
you also said I am not the first one, who is reporting this problem.
you also have to admit, that this approach to calculate difference in the working space based on timestamp is not very much efficient. too much work, which takes too much time.
and honestly, I don't understand why this approach has been chosen at all? it is very natural just to obtain revision before "svn update" then run "svn update" then obtain revision and compare them.
or, like I suggested - even more simple. calculate working space used. run svn update. calculate used space again. which could be even faster, as you go to svn repo just once.
like I said - i believe playing with time is not the best thing at all... time is not reliable property at all. two machines on the network will never have the same timestamp. besides... let me ask you - up to what precision you are requesting time in the code? and what precision machine gives on the request? and what precision returned by svn?
perhaps he could a problem too? what do you think?
but, in general, again - I think using timestamp is not reliable and too complicated.
I am mechanical engineer by education... simpler mechanism - more reliable it is.
cheers,
Slava
There are IMO 2 different topics here:
I) you get an error in the subversion-plugin. You assume that this comes from the timestamp handling of the plugin. I'm not convinced that's the problem. What you can do:
a) ask for help on the users list
b) patch the subversion-plugin according to your suggestions and confirm that that's really your problem
II) you criticize the handling of timestamps in the svn-plugin.
I've not initially developed the plugin, so I cannot provide any detailed explanations, why the timestamp-approach was chosen. But I know that using timestamps has certain advantages (e.g. if you use multiple repositories / job or when using matrix jobs).
What you can do:
a) search for the existing issues in JIRA and add any new insights, if you have them
b) provide a Github pull request with the changes from I) b)
Hello,
I filed bug here and you have responded, I was assuming you are a developer for svnkit. I am sorry if you are not... then I am not sure why I was having all this discussing with you. I am not java developer and so, not going to make any changes to this code.
I am not sure also what kind of advantages this approach using timestamps can provide - to me it is not efficient and causes problems.
as you stated previously, I am not the first one who files this problem. so, problem does exist and needs to be fixed.
like I said in my previous email: when this happened, our build engineer manually runs svn command and it goes just fine. so, to me it indicates that problem is not in svn, but in svnkit.
if you cannot fix it in svnkit code... why did you reply then?
regards,
Slava
Hello, we have got similar issue. We have just merged two repositories, so the timestamps are no longer in order (e.g. newer revision has older timestamp, because it was added as a part of merging repositories). All builds are failing on Jenkins now, however Tortoise works fine. From our perspective this really needs a patch as we are completely blocked now.
Hello,
We have a repository full of revisions without date. I suspect it is due to the use of svndumpfilter.
Builds are blocked.
Same issue here! We suspect empty revisions are causing this error: After migrating to a new subversion server using svndumpfilter without --drop-empty-revs and --renumber-revs, the repository has lots of empty revisions which do not have a date set.
We're using SVN Plugin version 2.2. Upgrading might be an option (have not tried yet). Another would be setting dates on empty revisions, as shown here: http://docs.codehaus.org/display/HAUSMATES/Could+not+access+revision+times (have not tried either.)
We too experienced these issues.
During an earlier import from another repository, 45378 revisions had been left without a svn:date property, which caused the HTTP 500 error.
The svn:date properties were fixed using the set-svn-date script from http://docs.codehaus.org/display/HAUSMATES/Could+not+access+revision+times
(BTW: If you are going to use that script, you have to fix generate_propsets to take in an URL parameter)
This is still a major problem, as we cannot prevent this from happening again while allowing our developers to do svn revprop changes (which is necessary).
I think this logic of using revision datestamps is severely flawed, because you cannot trust the timestamps in any way!
Even if you make sure that every revision has an svn:date timestamp, there are several scenarios which can result in an inconsistent timeline.
The revision numbers are "right there" and easy to get, and they are guaranteed to be consistent - why not use them?
We are using Jenkins 1.596.2 with subversion plugin 2.5 and can then observe exact the same problem. With subversion plugin 2.4.5 everything is okay. Switched back to 2.5, same problem again. However with subversion plugin 2.4.5 we cannot use the the subversion plugin as of 2.5. So this is a real blocker for us. As this is not the first problem with the subversion plugin, I am currently trying to replace the subversion plugins by scripts which call the command-line subversion tool.
For reference, here is our stack trace, maybe the slight differences are a result of calling it from workflow plugin, but the error occurs in every job, regardless which type:
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS of 'xxxxxxxxxx': 500 Internal Server Error (xxxxxxxxxxxx)
svn: E175002: OPTIONS request failed on 'xxxxxxxxxxxxxx'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:106)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:90)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:764)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480)
at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833)
at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:875)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:66)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:18)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:115)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:170)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:133)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948)
at hudson.FilePath.act(FilePath.java:981)
at hudson.FilePath.act(FilePath.java:959)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:106)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:70)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousStepExecution.start(AbstractSynchronousStepExecution.java:34)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:136)
at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:100)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:45)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:15)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:69)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
at sun.reflect.GeneratedMethodAccessor293.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
at sun.reflect.GeneratedMethodAccessor293.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
at com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
at sun.reflect.GeneratedMethodAccessor293.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:58)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:145)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:268)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$000(CpsThreadGroup.java:71)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:177)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:175)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
at java.util.concurrent.FutureTask.run(Unknown Source)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:111)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Running: Allocate node : Body : End
Most probably this is neither a Jenkins / SVN Plugin nor an SVNKIT issue. It seems to be an issue of the SVN server.
We are getting the following output in jenkins console:
14:25:13 Checking out https://XXX at revision '2015-09-02T14:25:12.558 +0200' 14:25:13 ERROR: Failed to check out XXX 14:25:13 org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/svn/YYY/!svn/vcc/default': 500 Internal Server Error (https://XYZ) 14:25:13 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 14:25:13 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) 14:25:13 at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:202) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:178) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:187) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) 14:25:13 at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) 14:25:13 at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) 14:25:13 at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) 14:25:13 at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:115) 14:25:13 at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) 14:25:13 at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:170) 14:25:13 at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) 14:25:13 at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) 14:25:13 at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) 14:25:13 at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) 14:25:13 at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) 14:25:13 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2688) 14:25:13 at hudson.remoting.UserRequest.perform(UserRequest.java:121) 14:25:13 at hudson.remoting.UserRequest.perform(UserRequest.java:49) 14:25:13 at hudson.remoting.Request$2.run(Request.java:325) 14:25:13 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 14:25:13 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 14:25:13 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 14:25:13 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 14:25:13 at java.lang.Thread.run(Thread.java:745) 14:25:13 java.io.IOException: remote file operation failed: /a/file/system/location at hudson.remoting.Channel@704e71df:a_hostname: hudson.remoting.ProxyException: java.io.IOException: Failed to check out XXX
If we try to checkout using svnkit or native svn by HEAD or revisionnumber everything works as expected. But as soon as we are using the timestamp to checkout as Jenkins does we are getting an error.
Example with native svn (svn, Version 1.8.13 (r1667537))
svn --username auser co https://XXX -r {"2015-09-02 09:00:00"}
svn: E175002: Unerwarteter HTTP-Status 500 »Internal Server Error« auf »/svn/XYZ/!svn/me«
svn: E175002: Zusätzliche Fehler:
svn: E175002: REPORT-Anfrage auf »/svn/XYZ/!svn/me« schlug fehl: 500 Internal Server Error
At the moment our workaround is to append @HEAD to the subversion-urls
After discussing the problem on the subversion-users mailinglist (http://mail-archives.apache.org/mod_mbox/subversion-users/201509.mbox/browser) in my opinion jenkins' subversion plugin should not rely on timestamps at all.
saretter, I would like to help here. Do you think the problem is related with Subversion Plugin?
recena the problem itself in my point of view is originally a huge problem in subversion and how it handles revisions and history of commits. But after my conversation with Eric Johnson on the subversion mailinglist (http://mail-archives.apache.org/mod_mbox/subversion-users/201509.mbox/browser) I think there is no way to fix that on subversion side which led me to the conclusion that you cannot rely on any subversion-operation that somehow uses timestamps.
So I think it would be best if SVN-Plugin could be implemented not using timestamps anymore. But in my opinion that would require a lot of changes and I don’t have enough knowledge about the implementation of the SVN-Plugin to say whether it is even possible.
hello,
my I also suggest yet another approach.
1. cd to checkout directory
2. capture hd1 the amount of hard drive space taken
3. run svn update .
4. capture hd2 the amount of hard drive space taken
if hd1 != hd2 - there are changes in this working space - run the build. I think it will be even more efficient then local svn command, so less time spent on the build + more reliable.
regards,
Slava