At 7:50 PM -0700 10/2/07, Jack Repenning wrote:
>On Oct 2, 2007, at 6:55 PM, Steve Sisak wrote:
>>Passé or not, I still need to support Mac OS
>>resource forks, types and creators (those are
>>on their way back) and other Mac OS file
>>metadata.
>
>Yeah, I was afraid of that. Had to ask, you know.
>
>>But if you cast the problem as "support for
>>general MIME type decoding", that has general
>>usefulness. Supporting Mac OS files attributes
>>is just a test case.
>
>Hey, I like that "requirements judo"! I agree
>it puts the key parts of the change into
>somewhere useful to all platforms (I'm real
>paranoid about non-Mac developers breaking our
>Mac-o-syncracies - nothing personal, just an
>abiding sense of fragility).
Cool. Assuming that we're agreed that we're
working on a part of a general solution, let's
scope it way down to something that can be
implemented.
I have 1 requirement: That storing and retrieving
a file in svn be a lossless operation.
(A pretty basic requirement for a version control system, don't you think)
In the case of Mac OS, this means that I get back
the whole file -- data fork, resources, type,
creator, script code, creation date, etc.
This applies to other platforms as well. If a
version control system can't preserve the
(entire) contents of a file over a check-in and
check-out on the same platform, then it doesn't
have much standing to call itself cross-platform,
right? :-)
That said, if we scope the requirement slightly
to "lossless when checking in and out on the same
platform", this gets a lot easier to solve.
The idea is that, for files that are accessed by
more than one platform, the platform-specific
attributes are saved in a property that follows
the file around and ignored by platforms that
don't understand the additional information.
(It's my understanding that this is an intended
use of svn properties)
For files that are truly platform-specific, we
also have the option to simply encode them as
binary files and use the MIME type to indicate
how they are encoded. Platforms that don't
understand that encoding see them as binary files.
>>The MIME types for Mac OS file encodings have
>>been set in stone for at least a decade (maybe
>>2).
>>
>>Matt has proposed file:appledouble for the
>>property which contains the AppleDouble header
>>file (associate with a given data file) -- the
>>format of the contents has been defined since
>>A/UX. Unless there are major objections from
>>someone, it's fine with me.
>
>Why isn't the standard name for this property
>"svn:mime-type"? I think there are official
>standard MIME types for AppleDouble and -Single
>(multipart/appledouble and
>application/applefile, respectively), so
>anything with that MIME type could, by a Mac
>client, be exploded into the "real" file on
>checkout, and glommed back up on checkin, right?
>
>(Mental note about non-Macophilic file systems,
>like UFS, on Mac platforms....)
Getting back to this, let's focus on 2 encodings:
AppleSingle and AppleDouble as these are:
1) Both the same format and can share code
2) What Mac OS X uses to represent Mac files on non-Macophilic file systems
Both contain the entire file and all its extended
attributes in a well-defined (and extensible)
format -- the only difference it that AppleSingle
encodes everything in a single (binary) file and
AppleDouble leaves the data fork in a traditional
flat file (accessible by any platform) and puts
the Mac-specific bits a separate flat file
(called the header file, a.k.a. the ._ file).
(MacBinary and BinHex are older encodings
semantically equivalent to AppleSingle -- these
could either be supported directly or converted
to AppleSingle when importing the repository)
Matt's proposal for supporting AppleDouble in svn
is simply to check in the data file and attach
the header file as a file:appledouble property. A
patch is already available:
<http://www.ambrosiasw.com/~fprefect/subversion-appledouble.html>
AppleSingle can be implemented by encoding the
file on check-in and setting the svn:mime-type
property to "application/applefile" (or
equivalent for application/macbinary and
application/mac-binhex4).
The choice of wether to use AppleSingle or
AppleDouble is left to the user, depending on
wether the file is essentially binary or is a
"normal" file with some extra data attached.
A good 1st approximation is that, if the file has
a resource fork, AppleSingle should be used --
otherwise AppleDouble should be used.
It might also be useful to have a way to exclude
certain resource types as there are some
instances where resources are used to tack
"additional" information onto "normal" files that
need not be saved. For instance, most Mac text
editors use a 'CKID' to indicate a file's version
control status (modifiable, read-only, modified
read-only) and use the 'MPSR' resource to save
the current text selection, etc. across edits.
Once in the repository, if the file's
svn:mime-type is application/applefile it is
AppleSingle encoded on check-in, otherwise, if it
has a file:appledouble property (regardless of
MIME type), then it is AppleDouble encoded and
the property updated if any of the metadata has
changed.
Given that these are file system encodings, it's
probably reasonable to implement them directly in
the svn client and defer discussion of a general
MIME type handling architecture for a 2nd pass --
nothing precludes pulling the code out into a
wrapper at a later time once an architecture has
been designed.
Note that, while I've define everything needed
for Mac OS (because there's a critical need),
there's nothing here that's platform-specific in
that all that is needed is to provide a platform
property equivalent equivalent to
file:appledouble an define its contents. This
just happens to have already fully defined for
Mac OS for over a decade.
There, done. Any holes?
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 3 16:30:50 2007