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.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
