> ... I have never used MacOS or heard of these elusive "resource forks"
...
MacOS can optionally include a database as a component of any file.
This database is referred to as the "resource fork" (as opposed to the
"data fork" that stores an uninterpreted bytestream) and is
traditionally used to associate icons, file types, program resources,
and other information. The ability for any program to attach
information to any file for any purpose is one of the things that
contributed to the early richness of the Mac UI. (Many Windows programs
use the Registry database for similar issues; SVN clients use the .svn
directory; other systems have other mechanisms for storing per-file
information, but the MacOS approach is arguably the most natural one.)
In order to transfer full MacOS files through various mechanisms (email,
for example), there are a variety of encoding mechanisms that archive
the entire file (including resource fork, data fork, attributes, etc.)
into a single stream of bytes. This is essentially no different than a
Unix user packaging a file with "tar" or "shar" to ensure that the
correct permissions get restored at the other end. (Windows users
similarly sometimes package a single file with ZIP to ensure that the
correct filename and permissions get preserved through email or FTP.)
Other systems have similar issues: OS/2 has "extended attributes",
POSIX 1.17e proposed a similar mechanism for Unix which is not yet
widely used, in part because it's not yet generally supported by
standard backup and archiving tools.
Right now, SVN is unusable for many MacOS projects because it only
stores the data fork. The Mac CVS clients detect MacOS files with
resource forks and encode them for storage in CVS. Similar capability
would be easy to incorporate into SVN clients.
> How does this square with deltification?
Well, today I can't store such files in SVN at all. I see that as a
much more serious problem.
>> Application #2: svn:encoding=gzip
>
>... why are you storing compressed files in your repository?
Because I have files that are >1GB uncompressed and less than 1MB
compressed. (In my case, these are test files that consist primarily of
zero bytes.)
> [You are just] trying to find justifications for adding some form of
resource fork support ...
That's a reasonable viewpoint. I look at it as "making it possible to
use SVN for older MacOS projects." Right now, I have an aging CVS
server on life support just for the benefit of a single MacOS project.
I would really prefer to use SVN, but there are no functional SVN
clients on MacOS right now.
> Where is the conversion performed? Client-side or server-side?
I envision client-side. Yes, there are issues with unsupported
conversions on the client. On the other hand, if someone on a Linux
platform really needs to checkout some MacOS resource files, they have
more serious problems than the fact that the underlying file has been
archived. I think that a warning in such a case "Checked-out file could
not be decoded" should alert to the user to the problem and give them
the opportunity to find a way to decode the file.
Server-side won't work because the server doesn't have direct access to
the client's hard disk, and therefore cannot implement any encoding that
requires accessing additional file information (such as extended
permissions, resource forks, etc.)
Tim Kientzle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 3 22:01:30 2005