Re: Severe speed problems with binary files

[Larry Jones]

John Beranek writes [quoting me]:
> 
> > 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).

If the documentation is segregated from the source code, you could
define a module that just includes the source directories (or,
conversely, that excludes the documentation directories) for your
developers to use.

> > 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?

        cvs ci -f foobar.pdf

>  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?

Once the default branch is switched to the trunk rather than the vendor
branch (which a forced checkin will do), it will.

> If so, I guess it'd also
> double the size added to each repository file for a change.

Correct.

-Larry Jones

Well, it's all a question of perspective. -- Calvin