Branko Čibej wrote on Fri, Mar 01, 2019 at 12:08:41 +0100: > On 01.03.2019 11:53, Stefan Sperling wrote: > > On Thu, Feb 28, 2019 at 10:44:25PM +0100, Denis Excoffier wrote: > >> Hello, > >> > >> The situation of the replacement of a directory by a circular symlink > >> generates an XML fragment which is invalid, hence triggers a failure > >> within the calling system. See hereafter the recipe. > >> > >> Starting from a clean folder, do the following: > >> > >> % svn mkdir 1 > >> A 1 > >> % rmdir 1 > >> % ln -s 1 1 > >> % touch 2 > >> % svn status --xml > >> <?xml version="1.0" encoding="UTF-8"?> > >> <status> > >> <target > >> path="."> > >> <entry > >> path="1"> > >> <wc-status > >> item="obstructed" > >> revision="-1" > >> props="none"> > >> </wc-status> > >> </entry> > >> svn: E000062: Can't open directory '/Users/dexco/svntest/svn/1': Too many > >> levels of symbolic links > >> % > >> > >> There is a missing end tag for <target> and <status>. > >> Another issue is missing output: path '2' is not listed. > >> > >> The correction of these issues will be much appreciated (i use 1.11.1). > >> > >> Regards, > >> > >> Denis Excoffier. > > Hi Denis, > > > > This problem is not specific to symbolic links. > > There are quite a few cases where --xml produces invalid XML > > when it runs into some kind of error. Perhaps the command > > line client should be fixed to close open XML tags when an > > error occurs, though this also risks people or scripts not > > noticing such errors. > > > > I suppose that, ideally, our XML output would embed errors > > inside the XML stream in a well-defined manner, as well as > > printing errors on stderr. > > > > So fixing this would require some non-trivial amount of effort. > > Would you have time and skills to work on this issue? > > My advice is to leave well enough alone. Any callers of our tools > _should_ check the exit code before assuming that the output is valid. > Just streaming the output through a SAX parser isn't the best strategy.
But there could have been tens of modified or unversioned <entry>s before the circular symlink. The size of output is O(N) where N is the number of interesting items found in the wc walk (= the number of lines in the non-XML `svn st` output). Internally we always process trees streamily; shouldn't we assume API consumers process trees streamily too? Secondly, I don't understand why there's an error at all. Shouldn't it just report an obstruction (dirent's svn_kind_t value changed) and move on? Cheers, Daniel
