slightly OT - differencing and version control

[Richard Gaskin]

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
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com