You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2003/12/01 20:28:27 UTC
Editing a binary property: propedit --editor-cmd
I should be able to edit a binary property like this:
> 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. It should only convert from and to UTF8 for the "svn:" properties. This requires a change to the interface to svn_cl__edit_externally.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Editing a binary property: propedit --editor-cmd
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
> > Nevertheless here is a description of a possible minimal support for
> > binary properties.
>
> I think I prefer the <name,type,value> idea to the idea of reserving
> part of the property namespace, which is ugly and not very flexible.
> (Example: with <name,type,value>, you could implement a property browser
> which shows icons as icons, because they are tagged as image/png or
> whatever. With the bin: namespace proposal, all you can do is avoid
> trying to display binary data is text.
Another idea would be to use "--binary" as a modifier, which would cause the
(binary) data to be uu- or base64-encoded and stored as text.
--binary would automagically convert back and forward in pe, ps, and pg.
So the proposed
svn propedit --editor-cmd=gimp-1.3 icon myfile
would work as
svn propedit --binary --editor-cmd=gimp-1.3 icon myfile
> But, as I mentioned in response to Jennifer Bevan, I don't think this is
> a 1.0 feature.
Agreed.
> > 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.
>
> "Properties about properties" would be ridiculous, but just a type
> doesn't seem like a bad thing. Your argument doesn't seem compelling
> enough to warrant pulling out the big veto hammer.
I live with meta-data for data in the windows registry - and it's (IMHO) just
for deciding which encoding to use for display/editing (strings as text,
binary as hexdump, dwords as numbers).
We could achieve something similar simply by storing the mime-type before the
base64-data; then any browser could decide how to display the data.
But I'd prefer to have that inline in the property-value - just to have the
thing and the type *really* together, and to avoid having (above mentioned)
meta-meta-meta-properties....
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Editing a binary property: propedit --editor-cmd
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-02 at 20:34, Julian Foad wrote:
> Nevertheless here is a description of a possible minimal support for binary properties.
I think I prefer the <name,type,value> idea to the idea of reserving
part of the property namespace, which is ugly and not very flexible.
(Example: with <name,type,value>, you could implement a property browser
which shows icons as icons, because they are tagged as image/png or
whatever. With the bin: namespace proposal, all you can do is avoid
trying to display binary data is text.)
But, as I mentioned in response to Jennifer Bevan, I don't think this is
a 1.0 feature.
> 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.
"Properties about properties" would be ridiculous, but just a type
doesn't seem like a bad thing. Your argument doesn't seem compelling
enough to warrant pulling out the big veto hammer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Editing a binary property: propedit --editor-cmd
Posted by Julian Reschke <ju...@gmx.de>.
Julian Foad wrote:
> 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.
Or a URI in the "data" scheme?
> 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.
Well, looking at de-facto usage of properties in WebDAV, I disagree.
There are numeric, boolean and date-typed properties everywhere, and
IMHO it makes sense to keep this bit of information. See
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html>
for a proposal how to marshal this type information through WebDAV.
Regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Editing a binary property: propedit --editor-cmd
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@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
Re: Editing a binary property: propedit --editor-cmd
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org