Attached is a patchlet that, when expat fails to parse an hunk of XML,
appends at least part of the offending hunk to the error message. It
provides a better jumping-off point for further debugging than the
current message, especially since the line number often isn't all that
meaningful. It's not intended to flag the error specifically, or even
to insure it's actually in the output fragment, since it'd be too hard
to reliably identify the problem. (For that matter, I can envision
cases where the error is actually in a previously parsed hunk of XML,
but doesn't become apparent until a tag mismatches in the current hunk
or the like.) By way of example, the current error message:
svn: Malformed XML: not well-formed (invalid token) at line 5810
becomes
svn: Malformed XML: not well-formed (invalid token) at line 3; XML starts:
>>>>>
<mv
dest=".svn/props/.ooo^H^H^Htestff^Hile.svn-work"
name=".svn/tmp/props/.ooo^H^H^Htestff^Hile.svn-work"/>
<readonly
name=".svn/props/.ooo^H^H^Htestff^Hile.svn-work"/>
<mv
dest=".svn/prop-base/.ooo^H^H^Htestff^Hile.svn-base"
name=".svn/tmp/
<<<<<
(I've expanded the BS to "^H" for legibility in this message; the
actual error message contains the original text.)
A few comments:
- The error message now extends over more than one line. I understand that svn
generally avoids this, but I think it's necessary to supply a
large enough fragment
that the user can make a well-educated guess about the location of
the problem.
The presence of \ns in svn-generated XML would also make it tough
to guarantee
that any meaningful fragment stayed on one line. Finally, trying
to flatten the XML to
fit on a single logical line would go well past 80 cols, which I
think would be more of a
problem than multiple lines that fit into an 80 column display.
- I chose a maximum fragment length of 240 chars arbitrarily, as long
enough to give the
reader some context and short enough to avoid a huge trail of text.
It seemed like a
reasonable balance to me.
- I placed delimiters before and after the XML with the thought that
it might help in some
situations where the XML itself started with odd characters; again,
this is relatively
arbitrary. It'd arguably be of some help for parsing the error
(the delimiters aren't
legal XML), but as this is a fatal and (one hopes) uncommon error,
I don't think many
people will be writing tools to anticipate it. If the consensus is
that they just add noise,
they're easy enough to drop.
Patched HEAD builds clean here, of course, and passes all but three of
the regression tests, none of which appear related to this patch.
'Nuff said about a minor patch for an infrequent occurrence. Chalk it
up to it being my first foray onto this list.
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 23 20:04:18 2005