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.
--
Les Mikesell
lesmikesell at gmail.com