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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
