Opening a Supercard file in Livecode?

[Richard Gaskin]

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