Thanks again for help on the tests! Responses inline.
>3 new test files attached for Streams and FileHandler directories.
>I have a slight concern with CvsStream in that it not only contains a=20
>Stream class but it also inherits from Stream.
>CvsStream overrides most of the Stream members and calls the same
>on the contained Stream. However it does not override all of the
>members, so if someone was to call one of these it would act on the=20
>inherited Stream and not the contained Stream, which is not what one
That might be a bad thing. I think that we can minimize this when we
start converting the public classes to internal. I have the nant builds
working again and just need to get the unit tests I broke back in the
good. After that maybe we can start looking at what needs to be made
>The easiest solution would be for CvsStream not to inherit from Stream.
>have tried this and everything still compiled, but I don't know if this
>will cause any problems for anyone else, or if the inheritance is there
>a good reason?
I am not aware of a reason. If it is an easy change to remove the
inheritance then maybe we should explore that. It might be a good idea
to add a few more tests for different protocols (ext/ssh) first on the
off chance that had something to do with the design. Just a thought, no
evidence to back that up :-).
>One other thing I noticed in the file handlers when both sending and=20
>receiving text files is that they make a physical copy of the file on
>hard disk (to simplify the process of converting linefeeds betwen
>and *nix). This seems particularly silly if you are using #cvslib
>linux/mono where obviously no translation needs to take place. I see
>reason why this couldn't always be done in-line which would save on the
>extra disk activity. Low priority I know compared to the other items
>need doing, but worth doing at some point.
I did not think about the line endings, this was one of the things I
assumed was being handled magically by the framework :-). I think the
temp files have two purposes then, one for the line endings and the
other to keep the memory footprint small if the client is bringing down
some larger files. Still I agree with you about performance, although
it would be a low priority item.
How does this sound: before the server sends down a file it sends down a
byte count. We do a test to see if this byte count is above a certain
threshold (probably on a per system basis, grab the memory installed and
only use a reasonable fraction of that) we spool, if not then we use an
in memory stream.=20
If that works for you then we can add it to a bug/feature request so we
remember it exists.