Compare files between on-rev and local versions

Alex Tweedly alex at tweedly.net
Sun Jun 21 19:08:26 EDT 2009


Sarah Reichelt wrote:
> Hi Alex,
> Many thanks for making this available. I definitely need it as I work
> on 2 different computers so am always at risk of using an older file
> and losing my updates.
>
> So far, I haven't actually set it working, as I am reading your
> scripts and learning how you did it.
>
> The button to save the irev file didn't work for me (no error, but no
> file created), so I grabbed the text directly out of the custom
> property, however it requires your html.irev include file. It may be
> that the only relevant bit from that is the definition of hBR, in
> which case that is an easy fix.
>
> I'll you know how I get on.
>   
Yes, hBr (defined as a global, and set by     put "<br>" & CR into 
hBR    ) is the only relevant thing in html.irev
I just defined a few html strings to make the code less "bitty" looking 
to me

Not sure why the iRev button didn't work - seems a fairly 
straightforward script (but it's been a while since I used the mac, so I 
may be doing something platform dependent). If you get a chance to take 
a quick look at why this failed, I'd be grateful.

The scripts are, I hope, fairly straightforward - even if not 
particularly well written. I have a lot to learn about sharing code 
between iRev and stacks.

The key decisions that lead to this approach are

1. You can tell absolutely NOTHING from comparing modification dates 
between two machines.

2. I am willing to assume that within a single system, a file whose 
modification date is unchanged has indeed not changed. (I know that 
logically this is not guaranteed - malicious code can determine a file's 
mod time, change system date/time, mod
ify the file and restore system time with the express intent of leaving 
the modification date unchanged. But that's beyond the scope of this 
application :-)

3. It is important to avoid shipping data over the wire just to compare 
it - so comparing md5 hashes is better than comparing files directly.

4. Line endings are a pain. In particular, if the client uses one kind 
of line endings and the server uses another, then ascii files will be 
converted during transfer - and then md5 hashes will come out wrong. So 
I took a simple minded approach and on the client I store 3 different 
hashes, calculated by substituting different line endings, and then 
compare the server file's md5 hash against *any* of those 3 hash values. 
This does increase the chances of an accidental "false positive" match - 
but that is still unlikely enough for this purpose.

However- I have realized that this technique (as implemented) is flawed. 
It will fail if the server uses CR+LF and the client uses anything else. 
I ought to add an extra case or two to handle that - but since the only 
existing Rev server today is on-rev, and it uses just LF, it's not very 
urgent - I'll do it along with the next change I find I need.

-- Alex.



More information about the use-livecode mailing list