Countering the usual diatribe against binary files, was Re: cvs diff, proposal for change

[David Clunie]

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.
[EMAIL PROTECTED] 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.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS and Jar files: Should you import Jar into the Repository?Why or why not

[David Clunie]

Hi

We currently have about 350GB of 1MB binary image files stored in a CVS
repository in order to keep track of who created them and when, and in
rare circumstances when they are modified or replaced, who did that and
when. The application has no need for concurrent merges, since the files
are rarely modified the ',v' files take up little more space than the images
themselves, and we have had no problems with cvs messing with the format
of the binary files (which are obviously checked in -kb). We have relatively
few users hitting on the system at one time which probably is how we get
away with it.

Essentially, we use CVS like a versioning filesystem in this application,
and while it may be a little slow and unwieldy, it gets the job done, at
essentially no cost and using a tool we were already familiar with.

The thing we miss most is an "ls" command via pserver (which we use
exclusively) but if we really cared that much we could add it I suppose.
We also miss a digital signature capability on checked in files, but again
we could add that if it really mattered.

So for everyone who says we shouldn't be doing this because it wasn't
designed for it, I say point us to a better tool that is as free and
accessible and familiar as CVS and can also handle all our text and
source files, and yes, Word and PDF documents too. We don't want one
tool for text and a different one for binaries, period. Maybe Subversion
will do the job when it is finished.

By the end of the year I expect to have several TB of images stored in
this system and I will let you know if and when CVS becomes a problem.

david

PS. I also store jar files and complete tar'd up releases and all
sorts of other things in CVS so I guess I am just a heretic.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs