Let's face it guys, anytime you have more than one "brain" working on
anything, the process is problematic. Even such tools as Apple's MPW,
developed specifically for team operations, was not easily groked by
most (IMHO). To expect that it would be any different with Rev is
pretty much a pipe-dream. To even think about it, much less try to do
it, may prove to be foolish what with all of the caveats.
Modularize the effort so as to have independent stacks or collections
of stacks, bring the fully completed modules together at the end
someway and then figure out how to divvy up the separate modules
amongst the team members for implementation. Maybe that seems obvious,
but it must be done at the very outset as a part of the
conceptualization or you're doomed to fail. Just my 2 cents worth.
(smile)
Joe Wilkins
On Feb 29, 2008, at 12:01 AM, Malte Brill wrote:
Hi Mark,
>Who is using RunRev in a group development environment? (reply if
you are)
Me :)
>How many developers are on the team?
Up to 5
>Are the developers in the same office or are the team members
spread over
>different regions or countries?
Most of the time same office, somtimes spread across regions
>How are you handling "master" stack updates to the server?
Very carefully. ;-)
>How do you handle "code" (.rev files) check-out and check-in?
SVN
>Bottom line, is RunRev a good tool to use in a production team
environment?
The file format is not really team friendly given its binary nature.
It boils down to that every team member is working on one module
(stack) at the time, which get loaded by a splash screen master
stack in the deployed version. If cards need to be in the same
stack, but different people are working on them, we either copy over
the cards, or ping ourselfs in an IM system. "Do you have xyz.rev in
use at the moment? Please check it in to SVN that I can do my bits"
And in a few cases this goes wrong. Given the binary nature of
stacks, SVN can not merge them, which is a pity. I wrote an XML
exporter for stacks, that can export a stack to XML and recreate the
stack afterwards. However, this has some difficulties, as there are
some properties, that can not be set by script (ID being one). So
one needs to design the stacks carefully (do not refer to controls
by ID) and I gave up on that approach.
>I ask these questions at this time after spending almost 2 years
using and
>learning RunRev on my spare time.
>It is starting to appear to me that it's a viable tool to use to
develop
>"off the shelf" software products.
Good tool with up and downsides in team mode. It plays nicer with
one man show companies.
>But with that in mind it's important to understand the questions
above, as
>one day this may be the tool of choice.
I hope my answers help a bit.
All the best,
Malte
_______________________________________________
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