Subversion and online code libraries!

[Richard Gaskin]

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