[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS and Binaries
From: |
Lee Sau Dan |
Subject: |
Re: CVS and Binaries |
Date: |
31 Oct 2001 10:38:31 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Guy" == Guy Scharf <address@hidden> writes:
Guy> Sau Dan Lee <address@hidden> wrote:
>> For your case, I think you'll be better of saving the binary
>> files with names containing version numbers (manually
>> assigned). There is no space lost with this method (since
>> there is no generic way to diff two binary files to produce a
>> minimal diff result). Moreover, one of the most useful
>> function of CVS is to diff arbitrary versions. With binary
>> files, you don't have this useful feature anyway.
Guy> I'm puzzled by what would be gained by saving two different
Guy> versions of a binary file as separate entities rather than as
Guy> a new version. If you have file.doc version 1.1 and commit
Guy> an update to 1.2, then the repository file.doc,v file
Guy> increases in size. If you add the new file as file-1.doc,
Guy> you've used approximately the same amount of disk space in
Guy> the repository, haven't you? The disk space will be in two
Guy> ,v files instead of 1. At least in browsing through binaries
Guy> in our repository suggests no space savings would result in
Guy> checking in the files separately as opposed to updating an
Guy> existing file.
Yes. So, there is negligible difference in disk space consumption.
But a very huge ,v file could be problematic. You know, CVS/RCS have
to look for tags starting with the "@" for the control information.
So, having large ,v files would make checkins and checkouts slow.
Guy> It's much more convenient, from a management point of view,
Guy> to use the update mechanism rather than to keep changing file
Guy> names. At least for binary files that change relatively
Guy> infrequently. I don't think that using CVS would be good for
Guy> binary files that changed frequently (such as a database).
Yeah, that's OK for *small* and infrequently changed binaries. E.g.,
I used to keep a "lib" subdirectory of some third-party (but
open-source) .jar files of my Java projects. When we feel we needed
to update those files (which is once in a few months), we simply
checked in the new .jar files and retest. So, we know which .jar
files worked with which versions of our own code.
--
Lee Sau Dan 李守敦(Big5) address@hidden(HZ)
.----------------------------------------------------------------------------.
| e-mail: address@hidden http://www.csis.hku.hk/~sdlee |
`----------------------------------------------------------------------------'