On Jun 1, 2005, at 8:58 AM, Ben Collins-Sussman wrote:
> On Jun 1, 2005, at 10:42 AM, James Berry wrote:
>> Subversion _should_ be made to do this. At that point, the fact
>> that there is a ._file on some file systems should be ignored as
>> an fs implementation detail.
> Not gonna happen. Resource forks are deprecated, Apple recommends
> against using them, and so there's no way Subversion is going to
> grow custom code to deal with them. This has been discussed many
> times before. :-)
Well, don't take my comments to apply only to resource forks.
The fact that OS X now supports extended attributes is good...it
joins a list of other platforms that support the same API for access
to extended metadata for a file. Other information is, and will, be
stored in EAs. The neat thing that Apple did with Tiger (even though
they too have been saying for years "don't worry about resource
forks...they're deprecated") is that they focused on the general
solution (extended attributes) and simply made the resource fork fall
into that category. They then made sure all the other tools (tar,
rsync, etc) supported EAs. And so they've killed multiple birds with
one stone, and along the way created a generic mechanism for getting
at extended file metadata.
So in suggesting that subversion support EAs and ACLs, I'm not
suggesting you support resource forks explicitly, but rather that you
support a generic, cross-platform mechanism for querying/manipulating
extended file metadata. There would seem to be a great mapping
between EAs and subversion properties. This would, implicitly, solve
the resource fork problem, but would also give you a generic way to
support any sort of extended metadata on files using a cross-platform
API. And file metadata, as we all know, is getting more important,
not less.
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 1 18:37:52 2005