RE: make cvs text agnostic?

[Paul Sander]

>--- Forwarded mail from address@hidden

>Okay, agreed, but let me put it this way:

>you are working on a project with files called *.doc, some containing text
>and some containing binary. People have complained they don't like adding
>the -kb and many get it wrong.

I think the argument has more to do with how to correctly set the keyword
expansion flag.  Ideally this is done at the time the file is initally
checked into the repository, but the current mechanism gets it wrong
much of the time and a later correction is necessary.  And the correction
is often done after several users have populated their sandboxes with
incorrect state.

>do you
>a) take the error-prone option of people setting -k sticky flags themselves?
>(yuck!) (then they go and throw weird variants on it with keyword conversion
>and what not and see what happens)

This is the least desirable mechanism, but it's also the most viable in
the event that a correction is needed.

>b) say "well from now on don't call your text files *.doc, call them *.txt"
>c) invent a heuristic detector which understands 382 languages and 3483
>filetypes

>whatever little problems there may be, i really think (b) is the easiest.
>this really is a case of the "shortest path".

>if files don't have meaningful extensions, the purpose of which is to convey
>a unique file type, then the responsibility lies _there_ to fix the problem.
>autodetection of types is a drastically appaling workaround for something
>that just doesn't need to be a big issue.

Well, using file extensions really is a heuristic method to identify
file types, so (b) is really a subset of (c).  If you can count on your
file extensions, then more power to you.  Some of us need to do something
a little more sophisticated, such as search the file for a keyword, e.g. if
the file has no extension.

No matter how it's done, it's possible to become arbitrarily close to
100% correctness on the heuristic detector.

>(and can't cvswrappers files be defined on a directory level? then, wrappers
>could be set up for each folder and the different types of documentation
>stored in each one of these)

Another way to do it, of course, is to review all of the files being
exported and supply a 1-1 mapping between file names and type.  This can
be done either on the command line directly when adding files, or by
writing a light wrapper about "cvs add" and supplying a table.

>-----Original Message-----
>From: Paul Sander [mailto:address@hidden
>Sent: Thursday, 29 August 2002 10:16
>To: address@hidden; address@hidden
>Subject: Re: make cvs text agnostic?


>>--- Forwarded mail from address@hidden

>>re this conversation of file types -- why autodetect them, isn't that the
>>whole point
>>of a file type, given in every file's extension? heuristic detection of
>>binariness -- yuck!

>That only works if you have a strict naming convention.  The canonical
>counterexample is the ".doc" extension which can represent any one of
>dozens of data types, some of which are pure ASCII and some of which
>are not.  Many shops have never standardized the tool they use to produce
>documentation (and therefore have a few), and several tools default to
>that specific extension.

>>a mechanism already exists to tell with this problem -- why don't people
>>just make a whopper of a cvswrappers file and then be done with it?

>Because cvswrappers won't work with this counterexample.

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



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