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
> >>>>>>>
> >>>>>>>
> >>>>>>>
>
Received on 2012-01-19 06:09:29 CET