Re: Severe speed problems with binary files

[John Beranek]

Larry Jones wrote:
> Russ Sherk writes:
> 
>>How many revisions of the example file are there?  cvs speed may be
>>affected adversly by a large number of revisions of a binary file.
> 
> 
> There doesn't necessarily need to be a large number of revisions, there
[snip]
> For those who don't know, the way the RCS file format (which is what CVS
> uses) works is the "most recent" revision is stored intact, all other
[snip]

Thanks for explaining the intracacies of the file format, and why it's
creating the problem...

> longer to check out.  There are a couple of things you can do to improve
> the situation:
> 
> 1) Don't store large binary files in CVS.

Not really a possibility, as the component is sourced from outside the
company and contains all the sourcre code and documentation (PDFs) in
one tree. I guess we could delete the documentation on the trunk, which
would make normal checkouts quicker, with the negative side effect of
having to get the documentation somewhere else (I guess you could have
the vendor branch checked out regularly and available via a web server,
for instance).

> 2) If you insist on storing large binary files in CVS, keep them on the
>    trunk rather than in branches.  For files on a vendor branch, you can
>    force a commit to the trunk at the cost of making the repository file
>    even larger and making old vendor releases more expensive to retrieve.

How would I do that? Additionally, each time a new vendor release is
imported onto the vendor branch will the subsequent "cvs up -jOLDVER
-jNEWVER" copy the new revision onto the trunk? If so, I guess it'd also
double the size added to each repository file for a change.

> 3) Rewrite CVS to better handle binary files.

Not something I have the knowledge or time to do...

John.

-- 
John Beranek                         To generalise is to be an idiot.
http://redux.org.uk/                                 -- William Blake