Frank D. Engel wrote:
The problem with using SVN (or any other modern version control
system, for that matter) with Revolution is the fact that the "source
code" (stacks) are binary files. That's okay for simple versioning,
but it is somewhat impossible to "merge" changes of multiple developers.
Fortunately, in my experience it's rarely needed.
Admittedly that experience may be limited: the largest team I've
managed in an xTalk had only 20 developers, and most commonly the teams
I work with have only 3 or 4.
But with an average of about 12 product releases a year here, in each of
these cases we've needed no finer granularity than the stack level.
In fact, since both library stacks and UI stacks tend to deal with
specific areas of functionality, from a project management standpoint
there are many benefits to keeping the team member ownership tied to
that level of the object model.
If multiple developers need to work on a stack, it often makes sense to
let one finish before sharing it with another. If the stack is large
enough to warrant multiple concurrent programmers, perhaps that's really
a sign to think about breaking the stack up into more easily managed parts.
As Steven McConnell reminds us, adding programmers adds overhead, so
that a second programmer only results in a net gain of about 50%
additional productivity on average, with the rest being taken up with
the overhead of coordination. Each additional programmer adds a smaller
net gain, with coordination overhead increasing with team size. The rate
of these diminishing returns vary from project to project, but for every
project there is a point where the coordination overhead exceeds the
productivity gained -- truly a suboptimal team size. :)
Coordination overhead can be minimized to the degree that each
programmer is working in a discrete section of the program; the fewer
dependencies between modules assigned to different programmers, the
lower the overhead.
If a project is complex enough to warrant multiple programers, it's
probably complex enough to give some serious thought to how the code is
factored. If you're developing with an xTalk, chances are you'll find
that stacks make a natural dividing line that not only goes with the
grain of the object model, but also with effective use of that object
model in applying good team management practices which not only
facilitate team member communication but code maintenance as well.
The only downside is that the nature of Rev's unique
binary-objects-bound-with-code often means that off-the-shelf systems
for text-only languages don't work as well here.
The upside is that it's dirt simple to roll your own check-in/check-out
mechanism -- and Chipp already has a handy one available if you're
crunched for time:
<http://www.altuit.com/webs/altuit2/MagicCarpetCover/default.htm>
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.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
