> -----Original Message-----
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: donderdag 3 maart 2016 09:19
> To: Bert Huijben <b...@qqmail.nl>
> Cc: Branko Čibej <br...@apache.org>; Subversion Development
> <dev@subversion.apache.org>
> Subject: Re: Incomplete xml output when using --xml to non-existent server
>
> On Wed, Mar 2, 2016 at 8:14 PM, Bert Huijben <b...@qqmail.nl> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Branko Čibej [mailto:br...@apache.org]
> >> Sent: woensdag 2 maart 2016 19:08
> >> To: dev@subversion.apache.org
> >> Subject: Re: Incomplete xml output when using --xml to non-existent
> server
> >>
> >> On 02.03.2016 15:05, Johan Corveleyn wrote:
> >> > Hi all,
> >> >
> >> > A colleague of mine ran into this, and I'm wondering if it's expected
> >> > behavior or a bug:
> >> >
> >> > For certain commands with the --xml option, the xml output is
> >> > incomplete when sending the request to a non-existent server. This can
> >> > cause an issue for tools that try to parse the output into some data
> >> > structure, and expect correct XML (even though the command has
> exited
> >> > with an error).
> >> >
> >> > For instance, 'svn info' and 'svn ls' behave thusly (maybe other
> >> > commands as well):
> >> >
> >> > [[[
> >> > C:\>svn info --xml https://nonexistent/svn
> >> > <?xml version="1.0" encoding="UTF-8"?>
> >> > <info>
> >> > svn: E170013: Unable to connect to a repository at URL
> >> 'https://nonexistent/svn'
> >> > svn: E731001: No such host is known.
> >> >
> >> > C:\>svn ls --xml https://nonexistent/svn
> >> > <?xml version="1.0" encoding="UTF-8"?>
> >> > <lists>
> >> > <list
> >> > path="https://nonexistent/svn";>
> >> > svn: E170013: Unable to connect to a repository at URL
> >> 'https://nonexistent/svn'
> >> > svn: E731001: No such host is known.
> >> > ]]]
> >> >
> >> > (The 'svn: Exxx' warnings are printed to stderr, while the incomplete
> >> > xml output is printed to stdout)
> >>
> >> This is clearly a bug; stdout should be either empty, or valid XML.
> >>
> >> In this case I suspect that we're printing the generic XML header too soon.
> >
> > We produce the output streamingly... would you suggest that we now
> buffer all output before producing the first result? (Potentially many
> hundreds of MB on recursive operations, so that would have to be a disk
> backed buffer when the amount of data gets huge)
> >
> > I think I asked the same question somewhere before 1.5, and the answer
> then was +- as I answered now... This is not really fixable in a backwards
> compatible way as there is no way to express errors in the schema. (How do
> we express an error to access a file somewhere deep inside a tree? That
> would make the entire tree invalid as expressed in todays schema)
> >
>
> Bert,
>
> Note that a failure to access a file / directory does *not* give this
> problem. This incomplete xml only happens when there is a problem
> accessing the *server* ("nonexistent" in my example).
Did you really try all error conditions of 'svn status --xml' without '-u' ? :)
There are hundreds of cases (if not far more) where common svn operations can
fail during an operation. Each will break the xml output.
I don't think it is valuable to fix just a few specific cases if we can’t
promise that it works in general.
'svn ls' is a 100% server side operation, so usually errors reported by this
will be related to auth and/or network problems, but svn info, svn status, svn
diff, etc. that also have --xml all have the same problem.
Bert
