Problem with Set Script in Compiled App

[David Burgun]

Hi Ali,

>David Burgun wrote:
>>Hi,
>>
>>There are a number of reasons to extract the Scripts of RunRev 
>>Objects into seperate text files:
>>
>>1.  We have to check files into a Source Database (Source Control 
>>System) and Binary Files are not handlied that well.
>
>Binary elements are not uncommon in databases.  It may be simpler to 
>upgrade to a more robust DB.

But not an option for me. Have been told that I need to check in text 
files, not binaries, and far from being simpler it would mean 
reoganizing Mega Byes of source code and distrupting an overwise 
working system!

>
>>2.  We want to be able to compare and exchange scripts from 
>>previous versions and to track the deleteion and additions of 
>>objects to the stack.
>
>This can be done easily in development -- why is that development 
>task better served in your workflow from a standalone?

Because it will be performed by a different department and they 
require a standalone app.

>
>>3.  For QA it is usefull to be able to take the latest GUI in terms 
>>of appearance and swop in older scripts, to pin point where the 
>>problems lie.
>
>Interesting idea, but if your code and your UI are that closely 
>bound maybe it's time to consider factoring most of the code into 
>libraries.

Would still have the same requirement if the code were in libraries.
>
>>4.  There are lots of expensive tools (which we have) for comparing 
>>and merging source code trees, exporting the scripts as files 
>>allows us use them.
>
>If you're heavily invested in "expensive tools" for this, a $99 copy 
>of DreamCard to handle re-assembly seems a small addition.

The requirement is for a Standalone Tool, the cost isn't an issue.


>>5.  We want be able to globally replace Text across a whole stack 
>>or project/application.
>
>Why can't that be done at development time?

It can, but we also want to be able to do it from a Standalone.

>Overall it seems the historical investment in tools designed for 
>traditional text-only languages is where you're having dificulty 
>making the parts fit with Rev.

Not really, the tools are recent and valid for wide range of 
languages including RunRev, in fact with the exception of the 10 line 
limit in restoring scripts, the export operation works just fine with 
the tools and adds a whole lot of power that is missing from the 
RunRev system.

>
>Rev is definitely a different way of working, and while it's 
>possible to jump through the hoops needed to coerce workflows 
>designed for very different tools to also work with Rev, in many 
>cases there are far more cost-effective ways to do the same job.

The only problem is the 10 line limit which we are hoping to addresss 
in the form of a license.


>Ken Ray, myself and others have written a wide range of custom tools 
>for managing small groups of developers contributing to a common 
>project.
>
>Chipp Walters has written one that's generalized for use with just 
>about any Rev project, and it runs from any FTP server with no 
>specialized server software:
><http://www.altuit.com/webs/altuit2/MagicCarpetCover/default.htm>

The point is that I have to use the company system not the other way 
round. RunRev is less that 2% of the total, they are not going to 
change the whole system to suit RunRev!

All the Best
Dave