Having read and considered the replies received thus far, I'm dubbing this a non-issue and moving on. Thanks for the feedback, all who provided it.
On 06/23/2011 03:15 PM, C. Michael Pilato 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?
>
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
