[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Ascii/binary detection.

From: <cmpilato_at_collab.net>
Date: 2001-07-31 22:34:04 CEST

According to the alpha-checklist.txt file, the problems--no, the
"challenges!"--of text/binary detection, keyword substitution, and
newline translation "will be solved by three separate properties":
mime-type, keyword substitution, and newline translation. Branko,
this is basically your brainchild, so I hope you're paying attention
to what follows (with your editor's red pen in hand!)

Confused as to why the mime-type was needed, I asked Karl the
reasoning behind this property. Karl explained that we want to allow
files to be marked as wanting newline conversion and/or keyword
substitution, but allow those attributes to be ignored for binary
files. That way users can enable those features for, say, '*' in
their working copy directory, and not have to worry about whether or
not each target in that directory is an ascii file. This is important
because a file's binariness can switch back and forth over the file's

I'm proposing the following:

1. Develop a heuristic for determining the binariness of a file, say
    svn_io_is_binary_file ()

2. During `svn add', svn_io_is_binary_file () is called (only on
    files, of course). If it returns TRUE, the property
    `svn:mime-type' is set on the file with a value of
    `application/octet-stream'. [NOTE: It'd be really nice at this
    point for the UI to say either "Added binary file foo" or "Added
    text file foo", but then again, it'd be nice if the UI said
    *anything* during an add].

3. At this point, the user can use `svn propset' (or `svn propdel')
    to change the values of svn:mime-type, svn:line-ending, and
    svn:keywords. We can also provide convenience subcommands for
    making these special property modifications, too (but don't make
    me pull out any -kkv's or anything!)

Now, a word about the values of these three properties.


    If this property is present on a given file, its value is used to
    determine the binary-ness of the contents of that file. Values
    for this can really be just about anything, but some notable ones

        'application/octet-stream' - Generic binary file. No keyword
                                     substitution or newline
                                     translation will occur on this
                                     file. Also, `svn diff' will not
                                     try to display a diff for this file.

        'text/foo' - Text file (where 'foo' is some
                                     mime subtype like 'plain' or
                                     'html'). Keyword substitution
                                     and newline translation are
                                     available for this file, and `svn
                                     diff' will actually display diffs
                                     for it.


    If this property is present on a given non-binary file, its value
    is used to determine how line-endings should be translated.

    Values for this can be:

        'native' - Use the line ending mechanism native
                                  to the user's operating system.

        'dos', 'unix', or 'mac' - Use CRLF, LF, or LFCR, respectively.

    Absence of this property means that no line-ending substitution
    should occur at all.


    If this property is present on a given non-binary file, its value
    is used to determine which keywords will be substituted in that
    file. The value is expected to be a comma-delimited list of
    keywords from the following set:

        'author' - replaces the keyword placeholder $Author$
        'date' - replaces the keyword placeholder $Date$
        'header' - replaces the keyword placeholder $Header$
        'revision' - replaces the keyword placeholder $Revision$

        ...and maybe some others, depending on whatch'all want.

    Absence of this property means that no keyword substitution should
    occur at all.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:34 2006

This is an archived mail posted to the Subversion Dev mailing list.