Re: [PATCH 0/4] teach vcs-svn/line_buffer to handle multiple input files

Jonathan Nieder wrote:

[*]
I am not sure whether this is the right approach for reading from the
report-fd.  To avoid deadlock, we cannot issue a blocking read(2)
after the trailing newline has been read from an expected line or the
nth byte has been read in fixed-length input.

I think this isn't a problem (even though I haven't found any
comforting text in the standards themselves).

To convince myself so, I wrote a couple of new tests.  The change
descriptions explain the reasoning.

These four patches apply on top of

  [PATCH 4/4] vcs-svn: teach line_buffer to handle multiple input files

and are numbered accordingly.  Thoughts welcome, as always.

Jonathan Nieder (4):
  vcs-svn: make test-line-buffer input format more flexible
  tests: give vcs-svn/line_buffer its own test script
  vcs-svn: tweak test-line-buffer to not assume line-oriented input
  t0081 (line-buffer): add buffering test

 t/t0080-vcs-svn.sh     |   54 ---------------
 t/t0081-line-buffer.sh |  174 ++++++++++++++++++++++++++++++++++++++++++++++++
 test-line-buffer.c     |   76 +++++++++++++++------
 3 files changed, 230 insertions(+), 74 deletions(-)
 create mode 100755 t/t0081-line-buffer.sh