Philip Martin wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>>svn propedit --editor-cmd=gimp-1.3 icon myfile
>>
>>/home/julianfoad/src/subversion/subversion/libsvn_subr/utf.c:170:
>>(apr_err=22) svn: Invalid argument svn: failure during string recoding
>>
>>... but it fails because "propedit" assumes that the property value is
>>UTF8 text.
>
> See "setting a convention for property values"
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=26473
>
> So the proposal is: let's declare all property values to be
> textual, and do UTF-8/eol conversion.
Wow. An interesting thread. That was before my time, and I've never heard it mentioned since.
We need something simple and consistent for release 1.0. (The current implementation is broken and inconsistent.) I support the proposal summarised above, and break it down as follows:
A: Basic proposal:
+ Declare all property values to be textual.
+ Store them in the repository in UTF-8 encoding, but always convert from/to the user's native encoding so that that is transparent to the user. In other words, do not frequently tell the user that property values are stored as UTF-8, but just say that they are composed of Unicode characters and are input and output in the user's chosen ("native") encoding.
+ If RA-DAV cannot transfer UTF-8 property values then teach it to do so.
+ Convert line endings in the manner of "svn:eol-style=native", i.e. store them as LF internally but present them in the style that is native to the platform in use.
I used to assume that binary properties were useful and that we would have them but now, after studying the issues, I have changed my mind. Their benefit is in allowing the main data of the property to be stored and retrieved without going through an encoder or decoder, but the disadvantage is requiring that any meta-data be handled separately which is a big increase in complexity.
I suggest that a binary value such as a graphical icon be stored as a block of text consisting of a header describing the file type (e.g. MIME type) and encoding, followed by the data encoded in some common text format such as ASCII-hexadecimal or base 64.
Nevertheless here is a description of a possible minimal support for binary properties.
B: Extension to also support binary properties:
+ The same as A except that we reserve some part of the property name space (e.g. names starting with "bin:") for "binary" properties.
+ Do not attempt to display or interpret such properties, e.g. in "svn diff" or "svn proplist --verbose", but only output one value at a time when specifically requested with "svn propget".
+ Provide no additional means for identifying the content type other than the property name and the content itself.
+ Make no rules initially about how to use them, but encourage such rules to be developed by interested parties.
+ Teach RA-DAV to transfer arbitrary property values before stating that this facility is available.
My suggestion:
+ Implement textual properties as in A.
+ Reserve part of the property name space for binary properties, as in B, either just by decree, or by emitting an "Unimplemented" error message when such property names are used.
+ Do not implement B for release 1.0, but wait to see whether binary properties really would be useful, and if they would, whether an implementation like B or something more complex would be required.
I vote -1 on providing _any_ additional mechanism for adding meta-data to properties. Properties are meta-data for files, so they should be simple and should not have a built-in mechanism for having their own meta-data. Such meta-data can already be included in the property's name and/or its value.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 3 02:30:42 2003