On 01.06.2005, at 17:58, 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. :-)
._ files can now contain more than just resource forks. As of 10.4,
they can contain a lot of other properties that people might
legitimately want to version, properties which Apple considers
important, which are advertised on the public Apple web site, and which
developers have been asking for, and so it would seem Subversion should
gracefully deal with them. We don't need lots of new features for
dealing natively with ACLs or other properties, but we do need a way to
not throw confusing errors and fail to work properly. You can consider
the behavior of 10.4's kernel to be a bug if you like, but it is
considered by Apple to be a new and nifty feature, and therefore is
unlikely to go away, and I admit that I myself have in the past been
left with many a ._foo when the foo to which it belonged had long since
been rm'ed, and this new feature will prevent that from happening. The
simplest way I see for Subversion to deal with this is to check if
running on 10.4 [1], and if so, when moving or copying a list of files
(or a directory of files in it), simply ignore any file ._foo where a
corresponding foo exists (since the OS will take care of them). And
prevent people from manipulating the repository's ._foo directly if foo
exists.
[1] Apple always warns against changing behavior based on the OS
version; it would be better to find an OS function call or library
whose existence one could test to figure out if this automatic ._
handling is in use.
---------------------------------------------------------------------
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:41:09 2005