|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
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