Open source collaboration [WAS: Re: Rev vs. AJAX... Ajax vs TAOO]

Chipp Walters chipp at
Mon Oct 17 01:41:26 EDT 2005


I agree, but like you, I tend to work alone, or with 1 other programmer. 
One of the things I really like about Rev, is the longer you program 
with it, the more it reveals itself as a fundamentally sound architecture.

Case in point. The reason I developed MagicCarpet initially was for a 
project where 3 rev programmers were working simultaneously. One was 
doing interfaces, while another was testing, and a third coding. It 
worked pretty well. But, as I move on, I find I really like to 'segment' 
my code into many different libraries and plugins. One of the great 
things about doing it this way, is you can create 'black box' objects 
which can be abstracted to a level where you can reuse them again and 
again. Another great advantage with numerous smaller stacks, is that 
you're only 'touching' one part of the code, and for large projects, 
that's just fine with me!

Some of my projects have in excess of 20 stacks. Each one is version 
controlled by MagicCarpet and when I upload a single stack, it 
automatically updates all clients in the field. By working with small 
stacks, I keep mistakes to a minimum.

Frankly, I can't imagine working on a team with a really large stack 
being shared by multiple programmers. OMG! The hair bristles on the back 
  of my neck just thinking about it. I'd much rather have you do one 
library, and Mark do another and me work on gluing them together.



Richard Gaskin wrote:
> Mark Wieder wrote:
>> What I'm interested in, though, is opening up a path to a more
>> granular approach to rev development. If you don't need to get more
>> atomic than one stack-one developer then you're home free. But if
>> you've got complex projects and need to have developers check out an
>> object from a stack, work on it, and check it back in, then nobody
>> else can work on that stack without the pain of merging objects.
> Can you tell us a bit more about projects you've worked on where 
> multiple team members needed to work on different controls in the same 
> window at the same time?
> This is different from my own, perhaps limited, experience, and any 
> toolmakers would do well to try to understand as many workflow models as 
> practical.

More information about the Use-livecode mailing list