info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Countering the usual diatribe against binary files, was Re: cvs diff, pr


From: David Clunie
Subject: Countering the usual diatribe against binary files, was Re: cvs diff, proposal for change
Date: Mon, 08 Sep 2003 13:48:30 -0400
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1

Greg A. Woods wrote:

1. keep your binary files in a separate manually managed archive.
...
"CVS supports binary files"?!?!?!?  No, I don't think so.  The '-kb'
"sticky flag" is just a terribly bad hack that gets more people into
more trouble with CVS than you could ever imagine because it gets
mis-interpreted as doing what you think it does.  It was not intended
for that purpose at all and it does not work the way you think it does.

DO NOT try to store binary files in CVS.

address@hidden wrote:

> We are currently storing gigabytes of binary data files in our CVS
> repository along with lots of text data.  We have found that if you
> remember to cvs add -kb from Windows (mandatory) or Unix (recommended),
> or to mark the files as binary after check-in under Unix *before* the
> first-ever modification is made, it can cope.  At the cost of
> performance penalties.
>
> But reading the above I'm wondering whether there's some other danger
> that we're unaware of, that would make us change our current methods.
>
> I've read the FAQ section on binary files, and found nothing there that
> I/we weren't already aware of.

We have several terabytes of binary files stored in a CVS repository.

Whether it be a "terrible hack", or a "misuse" of the tool, it seems
to work sufficiently well to get the job done.

We are not interested in merges, or diffs, or concurrency, we just
want the versioning and the log of "who, what, when and why" that
lives in the ,v files.

We don't care that inside they are not stored as deltas, we don't
care that each version is stored as all bytes in their entirety, we
just keep buying more shelves of disks in the arrays.

It would be nice if it were faster, but it is fast enough to meet
our requirements.

Going back to doing this manually would be a nightmare, a totally
untenable suggestion bordering on ludicrous.

Until there is a good, free, binary file version control system,
then cvs, with all its known limitations, fits the bill.

The "-kb" flag is the greatest thing since sliced bread, apart from
the long forgotten versioning file system of VMS that might also have
been a suitable solution for us.

If there is something "undesirable" going on inside CVS that is problematic,
I would be interested to know, but the empirical evidence would tend to
suggest otherwise.

david

PS. With respect to the original thread, since our binary files are
a) of a specific format, and b) we have tools equivalent to diff that
do comparisons of the content (for the purpose of human comparison
but not automatic editing or patching), yes it would be nice to be able to
parameterize or configure the type of diff used, without any expectation
that there would be any corresponding storage using "deltas" inside,
if these two operations are indeed separable.





reply via email to

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