An error may happen at any point during processing.
Agreed that if an error pertains to one specific target it'd be sane to
render the error as XML within that target's scope and render the
remaining targets normally.
But if there is a more global error (say: internal assertion triggered)
I think it still makes sense to have it on stderr so that one doesn't
have to parse screenfuls to get to it.
Errors on stderr are not rendered in XML.
Steven R. Loomis wrote on Wed, Jan 18, 2012 at 08:40:57 -0800:
> Daniel,
> I'm not asking to change the error condition.
> I guess I would prefer to emit an error in XML format, or to emit
> no XML at all. It doesn't seem like an "unexpected fatal error",
> especially because svnversion doesn't return an error.
>
> Perhaps,
> <info><error id="E155007">'/tmp' is not a working copy.</error></info>
>
> Thanks,
> Steven
>
> On 01/17/2012 11:16 PM, Daniel Shahaf wrote:
> >Or, are you asking that it doesn't consider "the target is not a working
> >copy" an error condition in the first place?
> >
> >Daniel Shahaf wrote on Wed, Jan 18, 2012 at 08:53:21 +0200:
> >>Why do you need well-formed XML when both stderr and $? indicate an
> >>error condition?
> >>
> >>Steven R. Loomis wrote on Tue, Jan 17, 2012 at 15:21:10 -0800:
> >>>svn info --xml gives malformed XML on error.. could it detect this
> >>>situation and still cleanup the XML, or not output any XML at all?
> >>>svnversion by comparison outputs 'exported'.
> >>>
> >>>-s
> >>>
> >>>$ svn info --xml /tmp
> >>><?xml version="1.0" encoding="UTF-8"?>
> >>><info>
> >>>svn: E155007: '/tmp' is not a working copy
> >>>$ svn --version
> >>>svn, version 1.7.2 (r1207936)
> >>> compiled Dec 2 2011, 15:21:13
> >>>
> >>>
> >>>
>
Received on 2012-01-18 18:26:26 CET