At 5:57 PM -0700 10/3/07, Jack Repenning wrote:
>The issue here is that both the server and the client have
>information about "the file." If you burst the AppleSingle/Double
>into an actual bundle or double-fork,
Woa -- I think I see what you're missing here. There's no bundle or
"double fork" there's only ONE FILE on the Mac.
The whole double fork thing is faked so that it's possible to access
parts of the file other than the data fork using POSIX APIs -- if
you're using the native Mac OS API there's only one file and if
you're on a native file system, there's only one object on disk.
You open the data fork with FSpOpenDF()
You open the resource fork with FSpOpenResFile()
You can open the resource fork of a file as a flat file with FSpOpenRF()
(I'm listing older APIs for clarity -- the new FSRef APIs support an
arbitrary number of forks per file and opening any fork as data or
resources)
>then the objects on disk at the client end (in the working copy or
>"WC") will be different, in number, content, name, and timestamp,
>from "the file" as perceived by the server.
There's only one file on disk and one file on the repository -- the
issue we're trying to solve is that svn only saves part of it (the
contents of the data fork) in the repository and discards the rest.
A bundle is a directory in the file system with a bit set in one of
the extended attributes (that isn't preserved by svn either) to
indicate that it should be presented to the user as if it were a
single file -- but on disk it's a directory tree.
>There's also a sort of a cache of this kind of info, in the .svn/
>directory: metadata in the "entries" file, a pristine copy of "the
>file" in the text-base/*.svn-base file, and so on. A complete
>implementation will have to do something or other about those.
I'll need to do some more research on that.
>For example, in all current cases, Subversion decides whether there
>has been a change in part by comparing the time stamp recorded in
>"entries" against the time stamp of "the file" on disk.
That's OK, because once "the file" has been decoded (or more
properly, reassembled), there's still only _one_ _file_ on disk --
it's now the whole file with all its parts.
>But if the server storage is, say, AppleDouble, then the most
>obvious implementation would make the .svn/ stuff AppleDouble, but
>the file on disk would be data + resource forks. When comparing
>time stamps, we would compare the time stamp in "entries" for the
>single AppleDouble file against the time stamp of which fork?
The file. There's only one file on disk. Only one time stamp.
Mac files have multiple forks.
The obvious implementation to me would be to make pristine copy in
text-base/*.svn-base a Macintosh file, with all its parts recombined,
rather than just the data fork of the original file.
>Would really have to be both, I think, since either can change independently.
There's only one timestamp because there's only one file once it's
been reassembled.
>If de-AppleDoubling the resource fork (or, whichever piece is done
>first) takes longer than a second, or takes a nanosecond but slops
>over a second boundary, then the file and resource forks have
>different time stamps, don't they?
There's only one file. :-)
>If we just accept that the timestamp comparisons are impractical,
>then we'll have to actually compare the files (not sure, but I think
>it's actually done by comparing MD5 sums, currently). This will
>require reconstituting the AppleDouble from its scattered parts.
I don't think this is an issue because, once the file is
reconstituted on Mac OS, there's only one file.
The difference between AppleDouble and AppleSingle only affects how
it's stored in the repository.
If it's stored as AppleDouble, then other platforms see the data fork
of the Mac file as a file (of whatever MIME type) that they can edit,
with a property containing the Mac-specific bits that are re-attached
if it's checked out on a Mac. (This would affect the modification
time of the file when reconstituted)
If it's stored as AppleSingle, other platforms see a binary file of
type application/applefile, which they probably aren't going to do
much with.
>This would be a big performance hit, and it comes up a lot (it's the
>basis of "svn status" and the icon badging done by GUIs, not merely
>checkin/update).
Probably not an issue if you reconstitute the file whenever it's on
the local file system -- it's only encoded when it's in the
repository.
Does this make sense?
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 4 06:14:33 2007