[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

'svn log' failure

From: <kfogel_at_collab.net>
Date: 2004-07-06 04:37:17 CEST

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:


It's using gzip encoding, naturally, so large swaths of it look like

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]
    # 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:


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

   - 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?


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

This is an archived mail posted to the Subversion Dev mailing list.