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.
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?
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.
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.
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?
6 We want to write an "include" file pre-processor that grabs functions
from a Common Include file.
You may find greater overall efficiency doing includes as part of
scripting, where you have the benefit of the script compile errors to
point you to anything that needs attention.
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.
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.
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>
It may not do everything you need, but may spark ideas for Rev-oriented
solutions to achieve the same practical benefits of what your system
does with text-only dev tools.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
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
