svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

I've found the following bug with Subversion 1.6.16:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025

The problem is: With the svn+ssh scheme, a ssh process is started and
sets its stderr to non-blocking mode. When executing an API-based svn
client with both stdout and stderr redirected to a pipe, output to
stdout (and stderr too, I suppose) fails with EAGAIN instead of
blocking when the pipe buffer is full. See the above URL for more
information.

"svn log 2>&1 | less" on a (big enough) svn+ssh working copy fails to
output the full log. It sometimes ends with:

  svn: Write error: Resource temporarily unavailable

I think the above test should be sufficient, but just in case, I've
attached (this is what I used for my Debian bug report):
  * a shell script bigrep to create a repository and a working copy.
  * a Perl script svn2log (based on SVN::Client) to reproduce the bug.

To reproduce the bug:

  ./bigrep
  ./svn2log bigrep-wc 2>&1 | less

and hit the [End] key. One generally gets:

[...]
2990
2991
2992
29
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000

lines 14957-15015/15015 (END)

Also:

tomate% ./svn2log bigrep-wc 2>&1 | wc
  26521 26553 123083
tomate% ./svn2log bigrep-wc 2>&1 | wc
  25701 25733 118987
tomate% ./svn2log bigrep-wc 2>&1 | wc
  25702 25734 118987
tomate% ./svn2log bigrep-wc 2>&1 | wc
  30012 30046 139467
tomate% ./svn2log bigrep-wc 2>&1 | wc
  30012 30046 139467
tomate% ./svn2log bigrep-wc 2>&1 | wc
  26521 26553 123083

As suggested by Niko Tyni:

  Possibly subversion should make a new descriptor for the ssh stderr
  and then shovel data between that and its own stderr.

You can also see what cvs did, because it had the same problem.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)