Re: binary files bad idea? why?

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ 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.

Mark's first assumption is totally reasonable, and it matches perfectly
the common usage model of CVS.

The second assumption can be implemented by storing the hint in a newphrase
in the RCS file.  I challenge you to find a situation in which adding a hint
in this way breaks RCS compatibility.  Chances are that the breakage willbe
in some third party tool that doesn't understand newphrases.  In that event,
it's the third party tool that break RCS compatibility, and you can't lay
the blame on CVS.

>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.

Okay, how does adding a newphrase break other tools that rigidly adhere
to the rcsfile specification?

>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.

The reason that the internal structure of a file changes over time is
because CVS makes no guarantee that every version of a file has the same
type over its lifetime.  There are ways to make such guarantees, but
at present they're limited to adoption of crippling policies or changing
the CVS implementation.  BTW, it turns out that the specific change that
makes this guarantee also fixes other problems in CVS.

>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).

It could be per-delta, but in my opinion that is a poor implementation.
The guarantee of one data type per RCS files makes a whole lot of
problems of this nature just disappear because all possible combinations
of data applied to the extensions match.

I believe that this is very much in line with "the RCS way".  Just take
a look at keyword expansion if you want a built-in feature that suffers
the same problem.  It also only works if the data type is similar for
every revision.

>--- End of forwarded message from address@hidden