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