Re: binary files bad idea? why?

[Greg A. Woods]

[ On Monday, July 12, 2004 at 17:10:46 (-0700), Mark D. Baushke wrote: ]
> Subject: Re: binary files bad idea? why? 
>
> It is a pity that you didn't bother to read what I wrote and instead
> ranted on a question that was not asked. Have you been ill? If so, I am
> sorry to hear it, please get well soon.

No, the real problem is you're beginning to get the same disease Paul
has suffered from for so many years.  You're not seeing the forest for
the trees.  You concocted a detailed micro-example to illustrate your
point without any consideration to the higher level concepts involved or
even any analysis of how your example might actually relate to higher
level concepts and requirements.

I don't think you're even paying proper and full attention to some of
the underlying reasons for doing change control in the first place.

You're clearly not yet grasping the full impact of what RCS
compatability really means and why it is so important to CVS users (not
CVS necessarily, but certainly CVS users whether they appreciate it yet
or not).  You seem to sometimes mime the idea of RCS compatability but
you clearly haven't integrated it into your thoughts enough that you can
see when and how a propsal wil interfere with, or even completely break,
it.

Perhaps all of this is my fault for not writing more lucid and detailed
descriptions of the ideas I'm trying to get across, but there are only
so many hours in the day and even fewer that I can use to enjoy in these
pursuits of intellectual discussion in public forums such as this one.

> Your entire reply to my previous message did not address any of the
> points or topic of my message

That's because what you (and Paul) are suggesting is what can only be
called a hack (and in my mind an ugly one at that) which goes in
entirely the wrong direction for all these underlying reasons of why any
sufficiently aware person would choose to use CVS (or any other
RCS-compatible) change control tool in the first place.

I'm not going to get sucked into debating artificially concocted
examples that ignore the bigger conceptual picture and which also ignore
a great many other lower level details as well.

I've been trying to _raise_ the level of discussion up to the concepts
and requirements where it _must_ occur before anyone can do any sensible
functional design or implementation (such as your contrived example
attempted to do).

> If you are not going to even bother to read what I write and not try to
> read between the lines, you are going to hurt yourself and burst a blood
> vessel or something...

If you are not going to even bother to try to read what _I_ have written
and to try to grasp the basic fundamental concepts I'm trying to relate
to CVS and to how CVS is, and could be, used, then we're not going to
progress at all.  You're focusing on the details necessary to prop up
your argument and I'm just not going to descend to the level of
discussing such details untill well after everyone's come to a consensus
about how things can and should work at a conceptual level.

Why don't you have a peek again at the discussion on effective ways to
use CVS with (La)TeX (or troff or lout or texinfo or whatever)
documentation.  Embedded in that thread is a hint to just how important
it is to work _with_ the ubiquitous nature of line-oriented diff/diff3
algorithms.  Stepping back a tiny bit from that thread and considering
all the unerlying reasons of why one does change control in such small
increments as something like CVS encourages will hopefully also let you
get at least a tiny hint of why it's important with any RCS-compatible
change control tool that the delta format inside the RCS files be
directly and intimately related to the format users see when they do
diffs and merges.  (hint:  unnecessary re-filling of paragraphs, or
changes to whitespace, makes diff (and thus RCS and thus CVS) treat any
file in a more ``binary'' fashion than necessary, no matter how
fundamentally text (line oriented) it appears to be -- I learned this
way back in the very early 1980's and I thought this was now such a
mantra amongst users of all version control tools that it didn't need
saying any more, but obviously that's not yet true)

Now if you (or Paul) personally don't want to use an RCS-compatible
repository for whatever reason(s) then you don't have to -- as you full
well know there are quite a good number of other tools out there already
that use other database formats that are more effective for the purposes
of pure delta compression (e.g. xdelta) and which always go to the
trouble of re-creating all file revisions every time they're needed in
order to do any and all presentation-level diffing and merging.  One of
those tools might already have the capability of using user-specified
diff and merge tools for a specified file, file type, or revision set or
whatever is appropriate for their model....

However keep in mind that CVS is today an RCS-compatible change control
tool and that this relationship is purvasive at many, if not all, levels
of its design and implementation.  Just because you or anyone else might
be able to envision some hack that verges on the stupidity of
cvswrappers to ignore RCS compatability and to relegate it to a job it
does only _very_ poorly for the kinds of things you would need this hack
to deal with doesn't mean such a hack is a good idea.

-- 
                                                Greg A. Woods

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