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