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

Extended attributes, again

From: Axel Dörfler <axeld_at_pinc-software.de>
Date: 2006-07-05 19:40:49 CEST

Hi,

I was looking into adding support for BeOS attributes to the Subversion
client "svn" via properties. I'm sorry that this also revives a similar
recent discussion that seems to have ended unresolved.

Anyway, this is what I want to do:
1) If you add a specially encoded property name like "beos:type:name"
   which could resolve to "beos:string:BEOS:APP_SIG" svn will monitor
   changes to the attribute "BEOS:APP_SIG" as it would monitor changes
   to "props". The property could get created automatically via a new
   "propset" option.
2) If requested (via config setting), the BEOS:TYPE attribute would be
   mapped to the svn:mime-type property.

My original plan was to hack this into "svn" and live with that. But as
I learned from maxb and sussman on #svn-dev, there is a similar problem
with the svn:executable property, which should also be monitored
externally, as well as that you seemed to be interested in having a
similar mechanism for extended attributes.

IOW, a more generic solution to this problem would be preferable. Since
that would also reduce the amount of work I would need to put into the
custom BeOS solution, I'd welcome this, too, of course :-)

I'm now proposing the following:
a) Properties can have a special flag that marks them as "extern"
   properties. For some properties (like "svn:executable" this is an
   implicit flag, for others, it could either be an option to the
   "propset" command, or if the storing backend doesn't support flags
   for properties (I haven't looked into that, sorry), the name must
   determine that flag.
b) if a property is flagged this way, instead of reading the property
   value out of "props", a new client function would determine if the
   client can handle that type of property - depending on the OS and/
   or file system features the working copy resides on.
   If the property cannot be handled specially, it will just be used
   as any other property, too.
   However, if the client is able to handle that property in a special
   way, the value in "props" will always be updated before use using
   another new client function that retrieves the value for the
   property. Therefore, when "svn update" or a similar command is
   issued, the value in "props" is always in sync with the working
   copy.
c) If a property has been changed via "svn update" (or "svn checkout"),
   another new client function will update the working copy
   accordingly.

Since part of that functionality is platform-dependent, it could be
implemented via registered handlers. For example, a standard UNIX
would add a handler for retrieving/setting the executable bit, while
the BeOS platform dependent code would add a handler for attributes
with the "beos:" prefix (or the "beos:*:*" pattern, if you prefer).

Problems of this approach:
p1) does not solve the size restriction problem of properties, and
    therefore is not adequate to solve the Mac OS resource forks
    problem. On BeOS attributes could have any size, too, so a
    maximum length for this mechanism should be specified. But
    that should have done for properties as well, obviously.
    Since changing the restriction of properties is not in the realm
    of subversion 1.x as I understand, Mac OS resource forks are not
    in the realm of subversion 1.x either.
    For subversion 2.x support for them could be easily added, though,
    by implementing a handler for this type.
p2) reduces the namespace of properties, and could clash with
    existing properties in a repository. The mechanism should
    therefore be turned on explicetly via config setting IMO.
p3) mapping the svn:mime-type field automatically could result in
    unwanted updates to repositories, or inconvience for the user
    in order to prevent such updates. For example, existing
    "text/plain" MIME types could be replaced by "text/x-source-code"
    after being edited on a BeOS platform.
    Therefore, that automated mapping should be configured via
    a config setting as well.

Any comments, or problems I didn't think of? Is there anything I left
out or open?

Bye,
   Axel.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 5 19:40:49 2006

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