RE: binary files bad idea? why?

[Greg A. Woods]

[ On Friday, May 21, 2004 at 09:22:04 (-0400), Jim.Hyslop wrote: ]
> Subject: RE: binary files bad idea? why?
>
> Greg A. Woods wrote:
> > There are also still many cases where surprises will crop up later,
> > often nasty and very difficult to deal with surprises.
> > 
> > Don't put binary files into CVS and expect it to work 100%.
> 
> Can you elaborate, or point to references please? At this point, all you've
> done is spread FUD.

Oh, come on now Jim!  If you can't remember then read the friggin' list
archives for goodness sake!

Or, just use your imagination and run some tests on example binary files!

It's pretty damn easy to come up with many scenarios where binary files
cause difficulties with what would otherwise be very "normal" CVS
activities.

The more, and the larger, the binary files you have the more headaches
you'll face, especially if you try to use any significant portion of the
full functionality CVS provides.

If this isn't blatantly obvious to everyone who knows that CVS uses RCS
under the hood and that RCS uses the unix diff and patch tools to
calculate and merge change deltas then those who don't get it need to go
back and take comp-sci-101 over again.  Yes it would be really nifty if
we all had some fancy tools that could do syntactically correct delta
detection and merging, regardless of the file syntax and if RCS and CVS
used those tools, but that's not how RCS or CVS works and there's no
point to pining over it.

Note also that "-kb" doesn't really mean "binary" despite what everyone
here keeps pretending -- it just means "don't mess with my line
separators or terminators and ignore whatever you think is an EOF char".
It is certainly not a panacea for using CVS to manage binary files.

There is no really good reason to put a few binary files in CVS when
most of the rest of your files are "normal".  It's much easier and
cleaner to use your external configuration management and build systems
along with some other (perhaps even extremely simple) archiving tools to
integrate the right versions of those binary files at build time.  Use
the right tool for the job and get on with it!

There is certainly no point to using CVS for all binary files since
almost none of what makes CVS really great to use would be of any use to
anyone with only binary files and there are more than enough alternative
tools that deal much better with binary files (though of course anyone
trying to deal with managing change control in binary files really needs
to think harder about what they're doing and maybe also go back to
comp-sci-101 again, especially when the file internal format is opaque
to the change identification and tracking tools).

Has everyone forgotten or failed to pay attention everything learned
about change management and control in the past 25 years or more?!?!?!?

Is everyone still stuck on the "I have a hammer so everything is a nail"
problem?!?!?!?!?  Is everyone so afraid of learning to use a new tool or
so that they can't get past the tiny little bit that they know?

Get over it guys!  Binary files and CVS do not, and will not, and
cannot, ever mix _well_.  Hacking around with one or a very few such
files in a limited range of scenarios is OK, but giving generic advice
to the public is quite another thing, especially when it _should_ be
peppered with so many disclaimers and "gotchas" that any sane person
would turn and run.

Don't put binary files in CVS and expect it, i.e. CVS, to work 100%.

If you still don't understand why then play around with "diff" and
"patch" for a while until you do.

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>