Hello, has anyone considered storing SHA hashes of node's text inside the sentinels so that Leo can much more intelligently decide what to do in case of such conflicts? It would also help with clone wars. I don't use clones at all currently despite they are very desirable feature. Since I somehow can't restrain myself to the right workflow - even without considering merging external changes, I sometimes keep editing the same @file in Leo and elsewhere, silly me :(
So, how it would work: On any refresh or save operation, Leo computes hashes of all clones it suspects may have changed, considering both in-memory and on-disk copies of nodes. It compares these hashes to hashes from sentinels. 1. All hashes from sentinels match, but one copy's data does not match the sum - we assume this is the newer version and update all other copies data and hashes. 2. Either the hashes in clones/copies sentinels differ, or more than two versions of data found - user must resolve, same behavior as today (asking yes/no to overwrite). The 1) case would AFAIK solve large part of today's problems because we now know per-node what is original and was updated, without relying on order in leo file plus whether a file has been/not been read yet. However I'm aware this may be complicated to implement, as it needs two-pass save approach. Juraj On Saturday, October 12, 2013 10:02:43 AM UTC+2, Matt Wilkie wrote: > > On Thu, Sep 26, 2013 at 9:51 AM, Edward K. Ream > <[email protected]<javascript:> > > wrote: > >> BTW, there is always a workaround to problems with refresh-from-disk. >> Simply save the .leo file and reload. The save will be safe for never-read >> @<file> nodes, provided that you say "no" when asked whether you want to >> overwrite the existing file! > > > > Unfortunately, I have more than once or twice nuked an external file by > answering "yes" by mistake. It usually happens when I've added a few new > files in one session and have lost track of which is which. > > My response has been to take it as a reinforcing lesson to be more > rigorous in using source code control and backups. > > The only interface improvement I can think of which would help resolve > this situation (and a number of other scenarios too I think) would be to > show a unified or side by side diff of the file on disk and the leo node in > memory. > > Such a feature would be tres cool, but likely involve a fair bit of work > which I'd be suggesting someone else do, which is why I've not mentioned it > yet. ;-) > > -matt > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
