> On 22 Aug 2017, at 3:17 am, Mark Waddingham via use-livecode > <[email protected]> wrote: > > work stopped on it when we reached a dead end with the dVCS 'stack dir' idea > - based on ideas Monte developed in lcVCS.
I can’t recall getting an explanation of what the dead end was but my guess is that it was fact that a merge conflict would be a nightmare to sort out and it is _very_ hard to write a non-lossy stack file format that won’t have a lot of merge conflicts If the goal of any array import/export of LC object is to create a mergeable file format then I wouldn’t bother. There’s just too much mingling of data and session state in LC objects. lcVCS just barely scrapes by if you have rigorous object cleaning scripts so that you don’t get merge conflicts on stuff like object sizes in a resizable stack. Not to mention the object ID merge conflict conundrum which needs a _lot_ of code to work around the fact we don’t have UUIDs. With script only stacks proving there’s significant utility in lossy file formats here I think the best solution would be something along the lines of the script only UI library I made where only a very limited subset of properties is supported, everything _must_ be uniquely named, no custom properties, no non-stack behaviors, only store the name of images used for icons etc. Just the absolute bare minimum to recreate the stack. Use something like YAML so it’s super easy to read and make it a single file so it’s not possible to get lost in an arcane directory structure. Cheers Monte _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
