[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 |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]