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:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
