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
_______________________________________________
Info-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/info-cvs
