I use a similar technique for storing stacks in SVN. When scripts are saved I have hooks which also export text files to SVN and write out metadata for indexing purposes.
I started with XML files, but as most of the changes were script based and I wanted the code readable and documented I moved the scripts into their own text files and use XML for the interface. I am not yet using the XML interface stuff - as I don't find it useful. I am at the moment storing binary stacks for minimal interface components ("views") and use text files to describe combinations of these into more useful and complex compound views. On 01/03/2008, Mark Wieder <[EMAIL PROTECTED]> wrote: > > Dave- > > > Saturday, March 1, 2008, 3:43:43 AM, you wrote: > > > > I found the best way to handle this was to export all the script as > > text files and them to a compare/merge of the source code and import > > the text files back into a "master" stack that is used to build the > > standalone application. For example: > > > That works fine as long as you're only dealing with script changes, > but not for UI changes. What happens if one of the developers needs to > add a field or a button to a stack? What happens if it makes more > sense to move a handler from a card script to a new button script or > vice versa? What if one makes a new custom property? Or worse, makes a > setprop handler for it? None of these are insurmountable, but they > take human mediation to resolve. > > > -- > -Mark Wieder > [EMAIL PROTECTED] > > > _______________________________________________ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution