Re: binary files bad idea? why?

[Greg A. Woods]

[ On Thursday, July 8, 2004 at 23:01:09 (-0700), Mark D. Baushke wrote: ]
> Subject: Re: binary files bad idea? why? 
>
> IF we assume that the 'cvs update' of a particular file in a user's
> sandbox needs to do a three-way merge (checked-out version,
> latest-version and locally modified version) AND we assume that there is
> a "hint" for the CVS server to use some program that looks just like
> diff3 as to arguments, but (possibly) interprets (say a canonical HTML
> structure ignoring whitespace) the file differently than the default
> diff3, AND the "diff3-like-progam" for the checked-out version and the
> latest-version specifies the same diff3-like program, THEN Paul's
> request for an extension seems reasonable to allow this kind of an
> extension.

Except those assumptions in total are bogus (and unrealistic), and they
do not leave one with a true RCS-compatible repository either.

Remember the whole point of RCS compatability is to be compatible with
other tools that understand and use the RCS ,v format.  It's not just a
convenient delta compression mechanism.  However the particular form of
delta compression used universally in the RCS ,v format is integral to
everything I know of which would rely on RCS compatability.

If you want to just compress deltas efficiently regardless of the
internal structure of the files being versioned then you should use
xdelta and give up entirely on the notion of RCS compatability.  That
way lies ultimate flexibility, but of course it's also the path to ever
more waste of computing resources necessary to reconstruct deltas in
more sensible forms for both human _and_ computer consumption, wether
that's the traditional diff/patch style or some other representation
suitable for non-text files, _every_ time they're needed.

Also within the architecture of CVS it's totally bogus, stupid, and very
short-sighted, to go blindly off and invent yet another ugly brain-
damaged hack that doesn't fully account for the fact that some
signifiant number of files' "internal structure type" (for lack of a
more succinct term) _will_ change over time in any sizable project.
CVSwrappers is bad enough for this reason alone already (never mind the
other brain-damage it implies) and luckily it's not used by many
otherwise sane people.  Any extension mechanism _MUST_ be per-delta, but
of course that goes against the very nature of RCS (and there are
already a vast number of attributes which are not per-revision but
should be to get to this level of flexibility).

> The lack of support for a per-delta newphrase that tells some version of
> CVS to use this other diff3 equivalent would not impact RCS nor would it
> impact older versions of CVS.

That's not the point -- why would anyone be bothering to use a change
control tool in the first place if all they want are archives of
revisions with delta compression for storage efficiency?!?!?!?

The whole point of doing change control is to capture (and be able to
reproduce, undo, copy, merge, etc.) the essense of the changes made, not
just to archive various revisions.  While one can pretend to do this by
reconstructing them every time using "the right tool" and re-extracted
copies of "the right revisions", that's (politely speaking) not a very
productive direction to go in when one is still using RCS in the
back-end.

As you full well know there are ample other available tools which are
better suited to doing this already too (and one widely used delta
compression algorithm to bind many of them together, conceptually at
least, if not with repository compatability :-).

IMVNSHO (and it has always been so) CVS could and should be making
better and more efficient and more effective use of the deltas stored in
RCS files, in their direct native format; not less.

-- 
                                                Greg A. Woods

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