I run this command just about every day:
$ svn log http://svn.collab.net/repos/svn/ trunk branches > log.out.tmp
Sometime today, it started failing (with very recent svn):
$ svn log http://svn.collab.net/repos/svn/ trunk branches > log.out.tmp
subversion/libsvn_ra_dav/util.c:670: (apr_err=175002)
svn: REPORT request failed on '/repos/svn/!svn/bc/10146'
subversion/libsvn_ra_dav/util.c:656: (apr_err=175002)
svn: The REPORT request returned invalid XML in the response: \
XML parse error at line 151235: Extra content at the end \
of the document
. (/repos/svn/!svn/bc/10146)
$
The log it produces is *almost* complete: it contains r10146 (HEAD) to
r33. The separator line after r33 is missing, as is r32 -> r1. Most
disturbingly, it appears that some of the logs that *are* present are
corrupted slightly (more on that below).
I can reproduce this reliably as long as I don't disable the
'http-compression' option in my ~/.subversion/servers file. Of
course, http-compression is not explicitly enabled by default, it's
just commented out, but that apparently means the default is "yes".
The ethereal trace of the erroring command is here:
http://www.red-bean.com/kfogel/svn-log-ethereal-trace-with-gzip.out
It's using gzip encoding, naturally, so large swaths of it look like
mush.
Next, I tried disabling http-compression, here's exactly how:
--- .subversion/servers~ 2003-12-21 08:26:57.000000000 -0600
+++ .subversion/servers 2004-07-05 15:42:36.000000000 -0500
@@ -63,13 +63,13 @@
### each pointing to a PEM-encoded Certificate Authority (CA)
### SSL certificate. See details above for overriding security
### due to SSL.
-# [global]
+[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
# http-proxy-host = defaultproxy.whatever.com
# http-proxy-port = 7000
# http-proxy-username = defaultusername
# http-proxy-password = defaultpassword
-# http-compression = yes
+http-compression = no
# No http-timeout, so just use the builtin default.
# No neon-debug-mask, so neon debugging is disabled.
# ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem
When I ran the command again, it seemed to work:
$ mv log.out.tmp log-with-gzip.out
$ svn log http://svn.collab.net/repos/svn/ trunk branches > log-no-gzip.out
$
No obvious errors here (but see below), and the log contains revisions
from r10146 (HEAD) to r1 this time. The ethereal log for the no-gzip
run is at:
http://www.red-bean.com/kfogel/svn-log-ethereal-trace-no-gzip.out
I diff'd the two logfiles, expecting exactly one hunk of all "+"
lines, since the no-gzip log contains r32 -> r1 and the with-gzip log
doesn't. I got that hunk, but I also got some other stuff:
$ diff -u log-with-gzip.out log-no-gzip.out
--- log-with-gzip.out 2004-07-05 15:31:20.000000000 -0500
+++ log-no-gzip.out 2004-07-05 15:44:08.000000000 -0500
@@ -95604,7 +95604,7 @@
(notify): Be more conservative about registering a change.
------------------------------------------------------------------------
-r2283 | kfogel | 2002-06-19 12:34:53 -0500 (Wed, 19 Jun 2002) | 56 lines
+r2283 | kfogel | 2002-06-19 12:34:53 -0500 (Wed, 19 Jun 2002) | 57 lines
Change commit/copy/import over to the new notification system. Now
only "svn merge" notification remains to be done. This resolves
@@ -95652,6 +95652,7 @@
* subversion/clients/cmdline/copy-cmd.c
(svn_cl__copy): Handle notification the new way.
+
* subversion/clients/cmdline/commit-cmd.c
(svn_cl__commit): Same.
@@ -112345,7 +112346,7 @@
callback baton, but just passed directly to the callback.
------------------------------------------------------------------------
-r1391 | gstein | 2002-03-01 03:58:04 -0600 (Fri, 01 Mar 2002) | 37 lines
+r1391 | gstein | 2002-03-01 03:58:04 -0600 (Fri, 01 Mar 2002) | 38 lines
Fix up the log functionality to properly deal with provided paths.
@@ -112371,6 +112372,7 @@
* libsvn_repos/log.c (svn_repos_get_logs): Make use of newly modified
svn_fs_revisions_changed. We pass it the paths passed to us (if
+
any). The returned array of revs is then used to trim down the
logs to just those that the caller is interested in.
@@ -122981,7 +122983,7 @@
Svn::RubyEditor#deleteEntry and Svn::CommitEditor#deleteEntry.
------------------------------------------------------------------------
-r661 | cmpilato | 2001-12-17 20:51:39 -0600 (Mon, 17 Dec 2001) | 212 lines
+r661 | cmpilato | 2001-12-17 20:51:39 -0600 (Mon, 17 Dec 2001) | 211 lines
Major migration of repository creation/opening code into libsvn_repos
from libsvn_fs (Issue #428). For consistency, the rest of the public
@@ -123129,7 +123131,6 @@
(svn_ra_local__split_URL): Use the repos API instead of the FS api
for opening repositories.
-
* subversion/mod_dav_svn/dav_svn.h
(dav_svn_repos): Add repos field.
@@ -128659,7 +128660,7 @@
for fetching properties.
------------------------------------------------------------------------
-r280 | cmpilato | 2001-10-22 15:04:14 -0500 (Mon, 22 Oct 2001) | 113 lines
+r280 | cmpilato | 2001-10-22 15:04:14 -0500 (Mon, 22 Oct 2001) | 114 lines
Patches very similar to those submitted by Mark Benedetto King
<bking@answerfriend.com> (I started writing this code on the train
@@ -128734,6 +128735,7 @@
* doc/.svnignore
* doc/programmer/design/.svnignore
* doc/user/manual/.svnignore
+
* doc/user/svn_for_cvs_users/.svnignore
* expat-lite/.svnignore
* subversion/bindings/guile/.svnignore
@@ -132097,3 +132099,234 @@
Add revision number to the subject line (and make an error statement
a little nicer).
+------------------------------------------------------------------------
+r32 | kevin | 2001-09-04 10:28:26 -0500 (Tue, 04 Sep 2001) | 34 lines
+
+Make build system work if Berkeley DB is not present.
+
[...]
(Everything from that point on is just r32->r1 "+" lines, so I've
omitted them.)
Notice how the difference seems to be the addition or deletion of
newlines, and what's really weird is that mistakes happen both with
and without gzip, even though only with-gzip produced a user-visible
error.
- In r2283, there is an extra newline in the no-gzip log.
I have confirmed that the line break is really not there in
the repository by logging into svn.collab.net and running
'svnlook log -r2283' directly.
Twilight Zone Extra: This extra newline does *not* seem to be
present in the no-gzip ethereal trace!
- In r1937, the with-gzip log has the error -- the addition of a
spurious line break, which is not present in the no-gzip log.
(Again, confirmed by direct 'svnlook' on the server.)
- In r1391, we're back to having a problem in the no-gzip log: that
newline isn't supposed to be there. (Same svnlook deal.)
- In r661, the with-gzip log incorrectly adds an extra newline, but
no-gzip gets it right. (svnlook again)
- In r280, the no-gzip log adds the incorrect newline, in the
middle of a file list. (you know what I'm going to say about
svnlook, so I won't bother this time)
Weird, huh? Those are all unusually long log messages, more than 30
lines each. But there are many, many other logs over 30 lines that
did not seem to have any problems (or, uh, if they did, they got the
same exact problem with and without gzip, 'cause they didn't show up
in the diff. I've also checked a few of them by hand, just for
sanity, and they seem okay.)
I didn't see any recent changes that looked suspicious, at least from
looking over my [only mildly broken] logs.
Can anyone else reproduce this?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 6 06:05:49 2004