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).
As I said in the second part of my mail:
> Contrast this with another failing request, when accessing a
> *non-existent directory* on an existing server:
>
> [[[
> C:\>svn info --xml https://realserver/svn/asdf
> <?xml version="1.0" encoding="UTF-8"?>
> <info>
> svn: warning: W170000: URL 'https://realserver/svn/asdf' non-existent
> in revision 316895
>
> </info>
> svn: E200009: Could not display info for all targets because some
> targets don't exist
>
> C:\>svn ls --xml https://realserver/svn/asdf
> <?xml version="1.0" encoding="UTF-8"?>
> <lists>
> <list
> path="https://realserver/svn/asdf";>
> svn: warning: W160013: URL 'https://realserver/svn/asdf' non-existent
> in revision 316895
> </list>
> </lists>
> svn: E200009: Could not list all targets because some targets don't exist
> ]]]
Accessing a non-existent directory on an existing server does yield correct xml.
--
Johan
