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
lifetime.
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.
`svn:mime-type'
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
are:
'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.
`svn:line-ending'
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.
`svn:keywords'
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