> > 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
Received on Wed Dec 3 08:10:47 2003