Re: [Cvs-test-results] CVS trunk testing results (BSDI BSD/OS)

[Derek Price]

Larry Jones wrote:

>I was thinking along the same lines, but most of the nightly tests don't
>deal with large files, so I'm not sure that's a valid test.  It might be
>better to time just the compression test that does use a large file
>rather than the entire suite.
>  
>

Good point.  Perhaps both would be in order.  Did you have any inkling
of how you would integrate "time" into sanity.sh?  Just log it for
review?  I would like to see it in the emails I think - I guess it could
be added to our nightly test wrappers as a fourth test
($builddir/src/sanity.sh -r src/cvs compression...).

Also, this doesn't work if I use random to generate a smaller (c. 24kb)
but uncompressable file for the compression test.  A separate set of
large file tests may be in order.

>ridiculously big read send_modified tries to do.  But buf_read_file()
>may require some changes -- it looks like buf_read_file expects the
>exact file size as an input and the client doesn't necessarily know the
>exact size, only an upper bound.
>  
>

buf_read_file_eof wraps buf_read_file with a call to stat to set the
size.  (It actually isn't being used right now as far as I can tell.  I
just noticed it and was thinking about removing it before you suggested
it may be needed.)

>That would only work for binary files -- for text files, we need stdio
>to do line ending conversions.
>  
>

Durn.  Missed that.  Well, buf_read_file would still avoid one copy
operation on the client.  Shame there's no way to avoid the full load
for text files, but they probably tend to be smaller anyhow.  Binary
files remain rare enough that I wouldn't think a special-case operation
would be useful, either.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:derek@ximbiot.com>