RE: cvs update; merge

[Greg A. Woods]

[ On Wednesday, August 29, 2001 at 15:53:23 (-0400), Jimm Grimm wrote: ]
> Subject: RE: cvs update; merge
>
>       Currently, 11 is the default option for all files.

Correct.  The default is to simply not cater to binary files -- they are
outside the scope of CVS' application domain.

>  It is possible
> to do 00 on selected files using cvswrappers.

Correct.  The silly cvswrappers hack adds minimal support for one "type"
of "binary" file.

Note that the goal of the cvswrappers hack was *NOT* to support the kind
of thing you're trying to do with CVS -- it was only to support a very
stupid type of programming environment where the names of some files
would change arbitrarily and the only way believed by some people to
store them in CVS was to "wrap" them in a .tar(.gz) file, which
coincidentaly is a true binary non-mergable file, thus the minimalist
support for true binary non-mergable files was unfortunately born into
CVS.

>       Would it be possible to generalize the cvswrappers file to the other
> two options, 10 and 01?

The correct thing to do is to rip the half-brained cvswrappers hack back
out of CVS and to forget that CVS could ever even contemplate storing
non-mergable files (be they binary from a libc fopen(3) perspective or not).

Non-mergable files can NEVER be easily and generically handled by CVS as
it stands today.  Until someone provides working code that makes the
diff/diff3 toolset used internally in CVS (and RCS) to be replacable
(preferably on a per-revision basis!!!!), there's no point to even
pretending that presently non-mergable files can be handled generically
by CVS.  (Of course with a selectable diff/diff3 algorithm you can treat
truly binary-opaque files with a "copy-to-merge" mechanism, though even
that's hardly 100% satisfactory.)

As for "binary" from the fopen(3) perspective of stilly petty OS
differences in EOL and EOF conventions, well since CVS cannot really
properly support non-mergable binary files the only correct thing to do
is to always treat all files as "text" files and to always apply the
local libc fopen(foo, "*t") conversions for the given client platform
(i.e. to always normalize the text stored in the repository into the
Unix/ANSI/ISO-C standard format where "binary" == "text" and EOL is '\n'
and there is no EOF character).

>       Of course this would still not be 100% foolproof, because someone
> could name a binary file with a name that is normally used for ascii, or
> vice-versa.

That's only 10% of the problem with binary files in CVS.....  i.e. the
tip of the proverbial iceberg.

-- 
                                                        Greg A. Woods

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