Post by giggzounetWe have a CVS repository with our program. In this CVS there are the
source, the documentation and misc utilities. In these
utilities there are binary archives (tgz), which contain test cases.
These archives can be quite big. I don't want that the CVS
make a version for each one (it takes too much place). But I want
that these test cases stay in the CVS repository and that they are
downloaded, if I do a checkout. Is that possible ?
There is no way to use CVS to store a file without a revision. You can
manage the repository to contain only one revision, but it requires
effort on your part, and depending on the scenario, could expose you to
technical difficulties.
As the other responder indicated, binaries should be added to the
repository with the -kb switch. After the initial commit, either never
commit again, or manually administer the repository as desired.
It sounds like what you want in the CVS repository is the latest version
of that file with no historical versions - retaining the ability to
update them now and again (otherwise I don't see how size is an issue).
A single commit has low overhead compared to the size of a large file.
It would only be the accumulation of history that would make size an
issue.
Say you add and commit one of these large binaries to CVS. It becomes
revision 1.1 (the repository size is only very slightly larger than the
checkout). Some time later, you update the test cases and you want to
replace what is in the repository, so you commit revision 1.2. Now the
repository size increases by the size of the new commit, and becomes
much larger than a checkout (after many more commits it is not hard to
envision someone having a concern about size if the files are huge).
If you then use something like `cvs admin -o 1.1 test_cases.tgz`, the
history for revision 1.1 is discarded and the repository size is
reduced. This is not typical use and is inherently dangerous. If you
accidentally delete the current version when you are in the habit of
deleting all prior versions, your data is lost from the repository and
hopefully there are copies of it that are recoverable that may be
recommitted. This also poses problems with pulling historical tags.
Say you have a tag that uses revision 1.1 of the test case, that
revision no longer exists (so one hopes the new file is backward
compatible), but it isn't necessarily obvious to a user what to do
when the checkout hiccups. Presuming that the test case is really
backwards compatible, you can change the old tag to point to the new
file so that checkouts don't hiccup, but then there probably needs to
be awareness that history is being modified intentionally (and that this
exposes you to risk that the tag is accidentally moved for other files
as well). I don't think you will find that this sort of procedure is
advocated by other CVS users.
What is probably better is that you commit some kind of script that is
routinely run after checkout that pulls the file from a file server as
that's really what you are asking CVS to do for you... of course...
that exposes you to risk that what is _supposed to be done routinely_
is forgotten, and someone creates a bug that was not caught by an older
test case suite, but then that's a discipline/management problem rather
than a technical problem created by using a tool in a way it was not
designed to be used.
Kevin Bulgrien
This message and/or attachments may include information subject to GD Corporate Policy 07-105 and is intended to be accessed only by authorized personnel of General Dynamics and approved service providers. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message.