svn - but smaller?

[mrboco at gmail.com]

> I'm sorry, but even ignoring all of your whitespace and style(9) 
> differences, your patch appears to go well beyond correcting a typo, 
> which I can't spot anyway, though I'm sure John will know what it is.
> 
> Care to explain a little more?

Sure. Typo is "strlen(command - total_bytes_written)" instead of "strlen(command) - total_bytes_written".

But then I've noticed that John have used non-blocking IO (useless in our case) while not handling IO errors, that lead us to permanent cycling on EAGAIN. So I've replaced John's code with the simpler one that blocks on write() and removed fcntl(..., O_NONBLOCK).

Then I've run a lot of tests again my own repository located on the same machine and sometime svnup was locked permanently with send/recieve queues filled up (remote fetching was OK). I've digged a bit in svn code and deceided that it would be helpful to use SO_KEEPALIVE and to set SNDBUF (at least) to the COMMAND_BUFFER value.

> Also, what advantage, in this particular case, is there in statically 
> linking?  Here it turns a 21.5K i386 binary into one of 575K.  If this 
> makes it into base, as I hope it may, that seems a little excessive?

There is no advantage. I've compiled both binaries for myself to be able to "svnup" hundreds of mahines w/o wondering about exact release =)