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 > >>>>>>> > >>>>>>> > >>>>>>> >
