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

Re: Mac OS X "resource fork" support

From: Marc Sherman <msherman_at_projectile.ca>
Date: 2005-08-13 15:29:27 CEST

Paul Sturm wrote:
> I would like to volunteer to implement support for Mac OS X "resource
> forks". So my first question is, is anyone already doing this? If not,
> then my second question would be, are there any particular plans as to
> how you would like to see this implemented?
>
> My basic idea is that the client would split off the resource fork into
> a "._" file, and submit that separately to the repository. (When Mac OS
> X copies a file to a filesystem that doesn't support resource forks, it
> does exactly this -- creates a second file with "._" prepended to the
> filename.) When a client, running on Mac OS X, retrieves this file from
> the repository, it would recombine the two files. On non-Mac OS X
> platforms, the client would simply leave you with two files. (This
> would be somewhat similar to the way symbolic links are handled on
> Windows.)

The problem with that approach is that it pollutes the file system name
space; on a cross platform project, users of other platforms would have
to be very careful not to create files with ._ at the start of the name.
  I would recommend a subversion property approach instead, either
putting the entire rsrc fork in props (such as macres:FOUR.id, where
FOUR is the four-character-code and id is the integer id), or following
your idea but adding a prop mac:resourcefork to both files to indicate
that the files actually are tied together.

- Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 13 15:30:22 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.