Compare files between on-rev and local versions

[stephen barncard]

I trust that a comparison feature, as well as basics like search and replace
will be added to the on-rev client soon.
Or better yet, offer a plugin method or source code so we can make our own
thin client or use it from within the IDE.
I have several features I need that I could whip up in minutes if I had
access.



-------------------------
Stephen Barncard
San Francisco
http://barncard.com


2009/6/21 Alex Tweedly <alex at tweedly.net>

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