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