Sean Carolan wrote:
Checking in binary files into CVS or any repository control system is usually a broken thing. You want to either check in the stuff inside the tar ball seperately (if its going to change), or just copy it into the archive by updating CVSROOT/cvswrappers
This comes back to the point of my first post - I'm looking for an *easy* to manage system to keep track of one directory of files that are updated once in a while. We're not working on a huge code base with multiple branches, etc. I suppose we can check in the files inside the .tar.gz separately but was hoping to avoid that since the contents of this binary are maintained by a different department. I'd really rather keep it intact as it is.
If the contents are text, one of the real values of a version control system is that you can do a diff between any two versions to see what changed. And ideally, you would push the access back to the people maintaining it so they could take advantage of the tools themselves.
Will SVN be better equipped to cope with large binaries?
SVN handles binaries moderately well and tries to just store the diffs even though they aren't usable for human viewing. The tradeoff is that svn keeps two complete copies in your checked out working directory and it wants to work on directories, not individual files.
I don't understand why CVS chokes on a 1GB file when all it has to do is move it from one directory to another. I even gave this machine 3Gb of swap so it had 5Gb of total memory space available but it still dies when doing a cvs checkout.
I don't think that should be a problem - but on the other hand I also don't think CVS is going to do anything useful with a compressed tarball. With either CVS or SVN, I'd recommend installing viewvc as a companion program. It will give you a nice web browser view of the repository with the ability to view history, diffs, and grab copies of files.