Re: Subversion and Macintosh resource fork

>
> 1. Apple's official stance on resource forks is that developers should
> move away from using them.

True...but they're still failry prominent...and by not supporting them
you're likely limiting Subversion to devlopers only.

> 2. Resource forks can be EXTREMELY LARGE, and while Subversion
> properties can be extremely large, I believe the recommendation is to
> keep them under 64K.

Sure for 'applications'..but for documents, theyre usually not that big
(probably 4-24k)

> 3. You can use Rez and Derez (shipped with Apple's Developer Tools) to
> pull the resource forks out of a file and into a separate file (in that
> file's data fork) and then put it back in.

I can fly to Tokyo to get to Paris as well.

> 4. This feature is completely Apple specific.

Maybe I wasn't specific enough regarding the implementation, but it's a
(addmitently simple) plugin architecture. I added a few hooks that will
load up a module to handle files if they can.

> Based on 1, 2, 3, and 4 listed above, I'm against adding this
> functionality to Subversion.

In 1.1.2 there was:
svn_wc__maybe_set_executable

now there's
svn_wc__maybe_set_executable
svn_wc__maybe_set_read_only

almost always following eachother in code...with roughly the same purpose of
looking to see if a property dictates that this file needs some special
operation in regard to the filesystem. And there will probably be more of
this as features are added.

Reducing these two to a single call that will handle all special cases seems
beneficial.

1. Code that is platform specfic will actually be moved out of lib_wc

2. Requests in the manner of 'I want Subversion to store 'x' information of
a file' will be easily answered...write a module.

Anyway, Resource forks have and will come up again by Mac users...would be
nice to have a branch to point them towards.

> PS With your address of 'spam_at_spam.spam', I have little hope of you
> getting this email unless you're subscribed to the dev list.

Sorry, trying to switch mail-clients....prooving to be difficultSorry,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 9 18:09:55 2005