Team Development using Run Rev

[Richard Gaskin]

mfstuart wrote:

> I have some questions as to even if RunRev allows itself to be a software
> development tool for development teams. So here are my questions:
> Who is using RunRev in a group development environment? (reply if you are)

Many here and elsewhere.

> How many developers are on the team?

Varies.  Most of my projects here use three to five; I've done one
project in another xTalk (Gain Momentum) that had a team of 25.

> Are the developers in the same office or are the team members spread over
> different regions or countries?

Often multiple regions, sometimes different countries.

> How are you handling "master" stack updates to the server?
> How do you handle "code" (.rev files) check-out and check-in?

Varies from project to project.  Sometimes a custom solution; with a
small, well-organized team we can get away with using email.

> Bottom line, is RunRev a good tool to use in a production team environment?

I'd say so, and the track record of this community, in which so many
people have had three or more programmers contributing to a project,
would seem to reinforce that.

As with any tool, the trick is to find the right dividing lines that 
make the most sense for the workflow.  With project management in Rev, 
the most popular approach is also the simplest: using stacks as the 
natural dividing line defining a discrete work unit.

If you want to have all your stacks as substacks in one stack file, it's
easy enough to clone them out with the clone command, and then integrate
them back into a mainStack by deleting the existing substack and setting
the new one's mainStack property.

But I find it even easier to just leave these stacks as separate stack
files, so that the EXE contains almost no code at all and everything is
handled in a collection of stack files in a Components folder that's in
the same folder as the app.  In OS X you could even put your Components
into the bundle if you prefer.

Not only are stacks a simple with-the-grain work unit in Rev, dividing
work with them makes sense logically as well.  You can put code into
library stacks, have UI views in stacks, and define things such that
each can be treated as a sort of black box, with certain things it
expects from the environment and things the environment can expect from
it.  Regardless of the physical structure of your project, factoring
things into "black boxes" is a useful practice that can make code more
robust from the start and easier to enhance and maintain down the road.

Here in my shop, most of the heavy lifting is done in libraries which
contain code broken up along logical boundaries, so that related code is
all in one place.  This also means that the code in the UI tends to be
very light, often trivial.

Gain Momentum had a built-in check-in/check-out system that worked at
the stack level.  Since I switched to Rev I more than a decade ago I
tend to use the same level of granularity in defining shareable work units.

Chipp's Magic Carpet is a good stack-based solution ready to go, and
others like Ken Ray and myself have written our own for some projects. 
Stacks are such a natural dividing line in Rev that even if you chose to 
write your own from scratch, I'd be surprised if you didn't have a 
positive ROI on the first project you use it on.  And if you use an 
existing one like Magic Carpet you can get instant results right now.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com