On Thu, Jun 23, 2011 at 3:15 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> When we designed 'svn log' many moons ago, we added the "N lines" header
> information to aid parsers of the output. Most of us had had poor
> experiences with parsers looking for sentinel lines which could themselves
> appear inside the delimited content. We didn't want to see folks writing
> scripts around 'svn log' and trying to look for lines consisting of 72
> hyphens, only to croak the first time someone's log message had -- you
> guessed it -- a line with 72 hyphens in it. So, we provided the log message
> line count. Parsers reader the header line, read any non-empty lines that
> follow the header line, skip the first non-empty line, and then parse the
> number of lines in the line count. Done deal.
>
> With the introduction of the --diff option, this algorithm goes to pot.
> Parsers can't even fall back to looking for a separator line after the log
> message, because the diff *could* carry the removal of a line with 71
> hyphens in it (which is, of course, represented as a minus/hyphen followed
> by 71 more of them).
>
> We discussed in IRC some solutions:
>
> - spool the diff, count the lines in it, and provide that count in
> some fashion
> - indent the diff by a single column
> - wrap the whole diff in some start/end markers ("[[[" and "]]]", e.g.)
>
> Keep in mind that the diff itself might be provided by a third-party tool
> ('svn log --diff --diff-cmd /usr/bin/shoot myfoot", as danielsh so
> eloquently put it).
>
> Thoughts?
Why do we have to do anything? There is no danger of breaking
existing scripts here because this requires adding an additional
option. Do we just feel like it would be impossible to parse the
current output? Can't --xml be used?
Mark
Received on 2011-06-23 21:19:25 CEST