On 8/13/05, Marc Sherman <msherman@projectile.ca> wrote:
> 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.
That would already be the case if the Mac and non-Mac systems ever
share a filesystem that does not support the Mac style resource forks.
While I personally don't like the "polution" it is already the standard way
the polution happens on other non-resource fork filesystem. Thus,
as long as SVN does not have good support for the resource forks
of the Mac, should not the Mac client act just like the Mac does with
other resource-fork challenged file systems/storage formats?
> 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.
That sounds much more hackish than what Apple already standardized
on with respect to other filesystems.
Plus, resource forks are now also considered in the xattr space of
the POSIX API. However, it is pushing things a bit to really do that
since xattrs were not initially designed for such potentially large
data elements. (Can you tell that I am not thrilled by the 10.4
"forks-are-xattrs" trick? I like it since xattrs are now copied via
cp/mv/tar/etc but it seems rather hackish... But maybe things
will get better when you can take an xattr and make it a first-class
file handle)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 13 22:35:25 2005