Hi,
In many cases like this the server really returns an HTTP status 500, but with
a detailed error report that the client should parse to find the detailed
error. I’m guessing this error parsing issue is already fixed for 1.9, that is
now in beta, where the whole error handling in our http/https layer was
refactored to be more effective.
The problem you see is that Subversion doesn’t really have an index on dates
and tries to perform a binary search on the revision properties to find out
which revision you really want based on the date you passed.
In theory you would be able to fix this by setting some appropriate svn:date on
all the revisions that now don’t have one, as I assume your commits in
chronological order.
(I’m guessing just copying the last seen date to all revisions that don’t have
a date would work for you)
Beer
From: Eric Johnson [mailto:[email protected]]
Sent: donderdag 2 april 2015 23:56
To: [email protected]
Subject: E160000 due to empty revisions when requesting log by date range (v.
1.8.11)
I've got a repository that has quite a number of revisions that are "empty".
Although I don't know the exact history, I'm guessing this is because we dumped
the repository, and ran it through svndumpfilter, but without the
--drop-all-empty-revs option, and without the --renumber-revs option. (Since we
have bug reports that almost certainly refer to the commit #, this seems like
desired situation.)
However, now, when one of my users tries to do:
svn log -r {2014-06-10}:{2014-06-15}
... Subversion fails.
If I perform the request with HTTP access, Subversion reports:
svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on
'_____/!svn/me'
svn: E175002: Additional errors:
svn: E175002: REPORT request on '______/!svn/me' failed: 500 Internal Server
Error
If I perform the request with file:/// <file:///\\> access, Subversion reports
svn: E160000: Failed to find time on revision ______
Since Subversion ostensibly supports empty revisions (otherwise svndumpfilter
shouldn't have the options to preserve them), it seems like a definite bug that
the date range log request fails.
It also seems like a bug that Subversion reports a 500 Internal Server Error
when used via HTTP. Since Subversion actually detected the error, it should
pass that error back to the client, so the client has more information about
the failure.
I looked for bugs that match this, and didn't find any. Should I file a bug? Or
am I doing / configuring something wrong, and there's a way to fix this?
I suppose one sort of work-around would be to go through each revision with no
date, and set the revprop date where it doesn't have one.... Does someone have
a script for that already?
Eric.
