Actually, I think plain text would work here better, unless arrays were stored 
in properties. Even then, you could save the arrays as text using the 
printKeys() function. There are text comparison utilities out there which are 
quite good at highlighting the differences between two plain text files. 

I think grouped objects would have to be kept together too. Easier to put back 
together later. 

This actually seems like the beginnings of a version management plugin. The 
bugger in all of it is that you would have to avoid recording object ID's, 
opting for the long names of everything. Also, behaviors would be problematic. 
They would have to be listed without the ID's of the objects they were set to. 

Bob


On Jan 24, 2012, at 7:17 AM, Richard Gaskin wrote:

> Pete wrote:
> 
>> All good points.  I guess I'm thinking of a different situation that
>> multiple people working on the same project.  When someone reports a bug
>> that crept into a particular version of an application, it would be useful
>> to see what changes were made to the stack that might have introduced the
>> bug.
> 
> That's a very good point.
> 
> It shouldn't be too hard to write a tool that can examine two sets of stack 
> files and produce a list of handlers which have been modified.
> 
> It would be a little tricky to write because we can't currently have two 
> stacks open with the same name, but I think it may be doable using something 
> like this:
> 
> The tool would create an array with object references as the primary key and 
> handler names as the secondary key, where the value is the handler definition 
> itself.
> 
> Then after it completes a scan of a given stack, it then goes through the 
> other version and compares the same handler definitions, noting changes, 
> missing items, and new items, and produces a clickable list of changes that 
> could take the developer to the script in question.
> 
> I'll add this to my "To Do" list; seems like it would be useful.....
> 
> --
> Richard Gaskin
> Fourth World
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to