> We 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.
