I find this a fascinating topic! The following thoughts are related to to a tool that identifies changes between versions of a stack. Recreating a stack is another issue. A full blown version control system is yet another issue and it's entirely possible that such a beast isn't possible with Livecode stacks if you want all the features of a traditional version control system. In fact, it probably isn;t since nobody has come up with one yet!
It's interesting that the opinions seems to be towards using an existing diff tool. I understand that, but those tools are based on text comparisons (I think) and other than scripts, we're not talking about text here, we're talking about objects. Yes, the objects in a stack could be reduced to text descriptions but somehow that seems artificial to me. On the topic of renaming an object, I don't think this is really an issue in this context. Object IDs within a stack don't change (except for stacks) so I believe any comparison has to be based on object IDs, not names. If the name of an object changes, it will simply be reported as a change to that object, just like any other property change. Of course this ignores the new ability to change object IDs and other "legal" means to change an object id, but if an object ID changes, then by definition it is a different object; the original object would be reported as deleted ( or still existing as the case may be) and the new one as being new. I see nothing wrong with that. I would be tempted to assign an altID to stacks (if not already specified) since they can and do change ID in a legal fashion but remain the same object. This is why I think the way to do this is with a database. Each object would have it's own primary key that would be a combination of its stack (alt)id and its own object id and would bind the db tables together to uniquely identify that object. The db would include a version ID for each version of a stack file. After that it would be easy to compare two versions of a stack and identify changes of any sort to an object using standard SQL and Livecode. For scripts, a gross comparison could be done with SQL (if scripta<>scriptb) and if changes were detected, hopefully there would be way to copy the scripts out to files, invoke a standard diff tool to identify the exact changes, and get the results back for reporting purposes. As for datagrids, the controls that are permanent fixtures of a datagrid are easily identifiable, the rest should not be considered in this scheme since they change dynamically every time data is loaded into a datagrid, not when the datagird structure changes. The job of a version comparison tool is to detect permanent structural changes, not temporal or data storage changes. The properties of the datagrid itself and the properties of the controls in it's template are all that matters since the latter form the basis for any temporary controls that are created in the datagrid. OK, time for another glass of wine! Pete On Mon, Feb 20, 2012 at 7:05 PM, Alejandro Tejada <capellan2...@gmail.com>wrote: > Hi Geoff, > > > Geoff Canyon Rev wrote > > > > [snip] > > For FileMaker, it's the easy database, but equally important, it's the > > fact > > that all items -- scripts, layouts, columns, tables, etc. -- are > > abstracted > > from their names. In FileMaker, if you change the name of a table, then > > everywhere in any script that refers to that table, the script changes > > automatically to match. Change a layout name, same thing. That's > something > > I wish every environment I use could have. Given that FileMaker has had > > this since at least 1994 or so, it's frustrating that no one else has > > picked it up. It's one of those things that seems obvious once you've > > experienced it </rant> > > > > So I agree, reconciling the source when someone changes the name of an > > object would be a pain. > > > > This is exactly the reason that drive me to ask > if it is possible to rebuilt a binary stack from xml > source: Does every control keeps its original ID? > > Because if that were the case, then it's only a matter > of use only IDs to reference controls in the scripts and > never, never use their names. > > This should be easy to add in the script editor as a menu > option selectable by the developer: > "Use only IDs References." > In this way, every time that you compile a script, the > script editor verify that after every reference to a control > there is the keyword "ID" and a valid reference to an > existing control or shows a warning to the developer. > > Another way is to make the conversion automatically > in the script editor while compiling, adding the > selectable menu option to: > "Convert Controls Names to IDs" > > Of course, if there is a message to catch a name changed, > like the message "selectionchanged" for selections, > then it's just a matter of writing a plug-in to catch the > renaming event and proceed to search and replace it > in all the scripts... (Honestly, I find scary an automatic > search and replace like that) > > Well, suppose that every challenge is sorted and it's possible > to use xml files with version control software as GIT for > teamwork in this platform, then... > Would be possible to use the browser to edit scripts and > control properties and using LiveCode Server to output a > binary stack to download and run locally??? > > Just a wild guess, but an interesting one! > > Al > > > > > -- > View this message in context: > http://runtime-revolution.278305.n4.nabble.com/Recreating-a-binary-stack-from-xml-text-tp4400122p4405848.html > Sent from the Revolution - User mailing list archive at Nabble.com. > > _______________________________________________ > 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 > > -- Pete Molly's Revenge <http://www.mollysrevenge.com> _______________________________________________ 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
