You may recall recent discussions about a bug in which
$ cd trunk/
$ svn log
returns logs for revs HEAD through 1531, instead of HEAD through 1.
Philip Martin and I have both seen this bug intermittently. We don't
have a 100% reliable reproduction recipe, since using the same client,
same server, and same working copy will sometimes show the bug and
sometimes not. But generally, when the bug happens once, it happens
again for a while thereafter. (I wonder if changing HEAD is a
Now I've used `ethereal' to watch the client<-->server dialog. You
can see the client request revisions 1605 through 1, and see the
server send back a report for 1605 through 1531. The server cleanly
terminates the report with "</S:log-report>" at the end.
(Note that we use the "S:log-report" element for both the request and
the response. I think I did that because the formal name of the
request method the client uses is "REPORT", and what it's getting back
is also clearly a "report". But if this is considered bad form in
http, please let me know and I can change it.)
Here's the client's request:
REPORT /repos/svn/trunk HTTP/1.1
User-Agent: SVN/0.10.1 (dev build) neon/0.19.3
...and here is the start of the server's response:
HTTP/1.1 200 OK
Date: Thu, 28 Mar 2002 17:33:32 GMT
Server: Apache/2.0.34-dev (Unix) DAV/2 SVN/0.10.0 (dev build)
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<S:log-report xmlns:S="svn:" xmlns:D="DAV:">
<S:date>Wed 27 Mar 2002 14:19:55.909988 (day 086, dst 0, gmt_off -21600)\
Have 'svn merge' use a genuine trace editor.
* diff.c (diff_or_merge): if an after-editor was passed in, compose
it with the diff editor.
(merge_cmd): stop dumping printfs.
... omitting log-items 1604 through 1532, here's 1531 and the end of
the server's response:
<S:date>Sat 16 Mar 2002 15:51:41.719537 (day 075, dst 0, gmt_off -21600)\
[huge (197 line) log message omitted to save your sanity]
Note the "</S:log-report>". :-(
So the question is, why is the server closing the report right after
revision 1531, when it still has 1530 revisions remaining to satisfy
Oh, some more data: just now it stopped at revision 10 (!), but then I
ran "svn log" again and now it goes all the way to 1 every time. HEAD
has changed from 1605 to 1606, but I don't know if 1606 was committed
already when I saw the HEAD->10 behavior. It was definitely committed
when "svn log" got all the way to 1, though.
The only way to debug this may be to run our live server
single-threaded under GDB, will warn before doing that of course.
Ben Collins, any thoughts? I'm looking at the rev 1391 change to
svn_repos_get_logs(), and the `revs' array in particular. No
particular reason to think the code has a bug, except that there's a
bug *somewhere* :-), and that seems to be the one place that might
filter out revisions in a plain "svn log" invocation.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Mar 28 19:24:17 2002