[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Severe speed problems with binary files

From: Larry Jones
Subject: Re: Severe speed problems with binary files
Date: Wed, 13 Apr 2005 16:19:34 -0400 (EDT)

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.


-Larry Jones

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]