Chris Sheffield wrote:
Anybody out there working on a team of developers? If so, how do you
handle file version control with your Rev stack files? I've been
using MagicCarpet (which has worked very well for me; thanks Chipp).
But up until now my company has only had myself and, at most, one
other developer, and MagicCarpet has met our needs. But we're getting
to a point where we need something a little more robust. Something
that will preferably allow multiple concurrent checkouts of files,
and then merge differences as they're checked back in.
Is there something like this that even exists? I realize since Rev
stacks contain binary data it makes things a bit more difficult. Is
there anything out there that can handle binary files this way? If
not, could something like this be created with Rev? If so, how
difficult would it be?
About half of the projects I've done over the last decade have been with
teams, usually with about three developers but the two largest had about
20 team members each.
One of those large projects was in done Gain Momentum (since renamed
RadBuilder), which has a stack-based MagicCarpet-like check in/check out
tool built in.
For the other large project (which used Rev) we wrote a custom version
control system focused at the card level which was specific to the
unique workflow of that system.
For smaller projects I've either custom-crafted a simple stack-based
system like MagicCarpet, or just assigned owners to specific stacks and
used email to trade them among the team. The latter has worked well
enough to keep the MetaCard IDE project running for several years
(though admittedly it's a small-scale project).
For the work that I've done I've found stacks to be a very natural
dividing line for sharing the workflow. Stacks tend to be either UI
elements or libraries, and it usually benefits the project as a whole to
keep the interconnections between such modules as simple and clean as
possible anyway, so divvying up the project by stacks lends a clarity to
the work.
Because most other languages make software out of hundreds of tiny text
files (as opposed to Rev's more self-contained binary files), there's an
inclination among multi-lingual professionals to think about solutions
for Rev projects in terms of what works elsewhere. But just as we enjoy
the simplicity of the object model, we can re-think old production
habits to discover ways to simplify the workflow as well, making Rev's
unique object model work for us. Go with the grain.
While it may be technically possible to atomize stacks into mergeable
parts (I've made a few myself as experiments, using XML and even custom
mini-macro-languages to describe objects), I don't prefer such a
workflow in production.
The overhead of coordinating among team members is high enough with the
even simplest tools and methods. Steven McConnell's research finds that
adding a second programmer adds only another ~50% additional
productivity on average, with the rest of the time spent coordinating
between programmers. A third programmer will add only another 30-40%,
and the rate of diminishing returns increases with team size. If the
team grows larger than the project warrants it could eventually result
in negative productivity, with more effort spent coordinating that coding.
So in short, team member coordination is expensive. Defining the
logical dividing lines of a project and assigning ownership of discrete
components to team members based on key competencies helps the workflow
parallel the execution of the code: each component should have minimal
connections to others, and putting the best mind on each component helps
ensure that it gets done well and with minimal interconnection issues.
If it appears that a particular UI window or library may best be served
by having multiple programmers working on it simultaneously, that may be
an indication of something very different, perhaps a need for
cross-training or team member reassignment.
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
