Jerry Jensen wrote:
Always take advantage of a good excuse to rewrite your code. The first pancake
is never the best one!
Well said.
The SC->Rev converter RunRev used to offer was okay but not completely
bug-free, and Ken's was more complete but it was so long ago and SC has
added so many objects since then that I don't know how valuable either
converter would be today.
But even with the best possible converter, Stephen pointed out the
weakness with such an approach: at best you're using only the features
that intersect between the two tools, so you'll never get an optimal
LiveCode solution with an automated converter.
I've done enough SC->Rev conversions over the years that I'm fully
convinced that automation is not the most productive thing to do.
Seductive perhaps, but not productive. You just miss too many
opportunities to streamline objects and code for LiveCode-specific ways
of doing things that it's almost always a better investment of time to
use the SC version only as an inspiration for making a native LiveCode
version from scratch.
As for XML version control:
It's possible to write an XML description of a stack and reproduce it
with complete fidelity. In fact, the ability to set the ID of any
object was added specifically to support such efforts, and I believe
such a project is in development now to help LC devs use standard
version control systems for larger projects.
But it's a lot of work and a lot of time spent on the version control
process that could be spent on product features, so the cost/benefit
analysis should be done carefully for the project at hand.
In my own projects I usually have teams of between 3 and 5 devs, and we
usually assign stacks to programmers according to their skills and
interest so there's rarely any overlap. In fact, the largest xTalk
project I ever managed had 20 devs building a CBT system for a Fortune
500 company and we still used only a stack-based check-in/check-out.
One of the attractions to more granular version control is the ability
to have multiple devs working on the same objects simultaneously.
But is that something you really want to do?
That seems more of a project management problem than a technical one,
raising questions about optimal skillset usage more than simple workflow
management.
Factoring a project into UI stacks, library stacks, and other
stack-based components can make it easy to manage teams of the size we
commonly see with LiveCode projects, using simple with-the-grain methods
of stack-based check-in/check-out like Magic Carpet and similar solutions.
Stacks aren't the ideal dividing line for all project management, but
for the sort of stuff we see in this community they often provide a
clean and simple solution that makes keeping things on track a breeze.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
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
