Re: Version Control Strategies For Block-Based Forths?
  Home FAQ Contact Sign in
comp.lang.forth only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: Version Control Strategies For Block-Based Forths?         

Group: comp.lang.forth · Group Profile
Author: John Doty
Date: Sep 19, 2008 15:11

John Passaniti wrote:
> John Doty wrote:
>> I don't recall any serious multiple developer issues with the boxes of
>> floppies approach. But it was rather different in scale from a modern
>> project. I have a printout of one of the last revisions done that way:
>> it was 33 blocks, and the blocks contained lots of white space. That
>> was about all that would fit in the little 1802. Something like 6-8
>> people made serious contributions to this code. I can't think of any
>> recent project I've worked on with so many contributing to so little
>> code.
>
> Not that it matters, but I'm curious: 6-8 developers, typically making
> overlapping changes? Or were developers typically responsible for
> non-overlapping parts of the code?

I don't recall a lot of overlapping changes, but there were some.
However, I also don't recall a lot of overlapping changes from the RCS
era, when it seemed like I was always breaking locks. Minor annoyances
stick in your mind. And I don't understand your metric for "typically"
anyway.

This was a rather disintegrated software system: just a bunch of Forth
(LSE) definitions that did useful things. The tendency when adding new
functionality was to add new words rather than change old ones. When the
code's well factored, this doesn't waste a lot of space (build new
commands on old factors rather than from scratch), and you usually don't
risk breaking something that might be a crucial part of some user's
standard operating procedure. So I suppose overlapping changes could be
considered rare. But again, there just wasn't a lot of code, so there
wasn't much to change. The Forth approach managed to create something
pretty capable with very small resources here.
>
>>> All this is being used as research for a new project at work with
>>> some unusual requirements that might lend itself to block-style
>>> development directly on the target.
>>
>> You deny the application matters, and then you tease us ;-)
>
> I deny the application matters... for the purposes of this discussion.
> That's an important qualification. I purposefully avoid the specifics
> of the application because I am *not* asking people to go into
> problem-solving mode and to discuss solutions. I am only, at least for
> now, interested in history.

Always walls. That's why dealing with programmers is so frustrating for
the rest of us.

--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
The axiomatic method of mathematics is one of the great achievements of
our culture. However, it is only a method. Whereas the facts of
mathematics once discovered will never change, the method by which these
facts are verified has changed many times in the past, and it would be
foolhardy to expect that changes will not occur again at some future
date. - Gian-Carlo Rota
no comments
diggit! del.icio.us! reddit!