You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Steven R. Loomis" <sr...@icu-project.org> on 2012/01/18 00:21:10 UTC
svn info --xml malformed XML on error
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
Re: svn info --xml malformed XML on error
Posted by Daniel Shahaf <da...@elego.de>.
That would also imply proceeding to the next target, right?
'svn info --xml /tmp /etc'
In short --- +1 to filing this as a feature request in the issue tracker
--- but I think there's seom work to be done on defining the new
behaviour more precisely. Unfortunately I won't have the time for that
work.
Steven R. Loomis wrote on Wed, Jan 18, 2012 at 20:55:10 -0800:
> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
>
Re: svn info --xml malformed XML on error
Posted by "Steven R. Loomis" <sr...@icu-project.org>.
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
>>>>>>>
>>>>>>>
>>>>>>>
Re: svn info --xml malformed XML on error
Posted by Daniel Shahaf <da...@elego.de>.
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
> >>>>>
> >>>>>
> >>>>>
>
Re: svn info --xml malformed XML on error
Posted by "Steven R. Loomis" <sr...@icu-project.org>.
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
>>>>>
>>>>>
>>>>>
Re: svn info --xml malformed XML on error
Posted by Daniel Shahaf <da...@elego.de>.
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
> >>>
> >>>
> >>>
>
Re: svn info --xml malformed XML on error
Posted by "Steven R. Loomis" <sr...@icu-project.org>.
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
>>>
>>>
>>>
Re: svn info --xml malformed XML on error
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
> >
> >
> >
Re: svn info --xml malformed XML on error
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
>
>
>