On Oct 3, 2007, at 5:20 PM, Steve Sisak wrote:
>> * client uses a heuristic to determine if file is changed
>> locally. In
>> this case, to check if a file is modified it would have to be
>> encoded,
>> and then if the size is not different, a byte by byte compare would
>> have to be performed.
>
> What's wrong with modification time? Mac OS modification time is
> only updated if a file (any part) is changed.
>
> In any case, this is no different that having 2 files plus a small
> fixed size header. How does the client currently handle a 1 byte
> write to the middle of a file (which wouldn't change the length)?
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, 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 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. 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. 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? Would really
have to be both, I think, since either can change independently.
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?
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.
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).
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 4 02:58:05 2007