My suggested change is as follows.
Besides the current output (including the unterminated "<info>"),
additionally output (on stdout):
<error id="E155007">'/tmp' is not a working copy.</error></info>
That provides some information in the xml rather than just failure.
-s
On 01/18/2012 05:02 PM, Daniel Shahaf wrote:
Well, yes, but backwards compatibility means that we have to keep it
returning an error ($? != 0 and stderr != ""), or we'll break everyone
else's scripts.
If you have a suggested change that is backwards compatible, we'd love
to hear it.
Steven R. Loomis wrote on Wed, Jan 18, 2012 at 10:27:45 -0800:
Agreed, errors can happen at any point- but this particular error
hardly seems like an unexpected internal fatal assertion, especially
given svnversion.
Thanks, not urgent for me, just surprising.
-s
On 01/18/2012 09:25 AM, Daniel Shahaf wrote:
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
