| Re: Version Control Strategies For Block-Based Forths? |
|
 |
|
 |
|
 |
|
 |
Group: comp.lang.forth · Group Profile
Author: Dennis RufferDennis Ruffer Date: Sep 20, 2008 07:17
On 2008-09-19 22:21:31 -0500, Albert van der Horst
said:> If I *had* to do it, I would keep a looseleaf printed copy of screens
> and keep track of dates. Then it is easy to have a new version in
> front of the old versions of screens. Screens are considered the same
> and differing in version based on the remainder of the index line.
> THe word .TRIAD suggests that printing screens was common.
> Old FIG screen doc's suggest this strategy, but I
> have never seen this explained.
I remember doing many paper comparisons, along the lines of the thin
paper overlay method described by John Passaniti earlier. The "triad"
was a classic printing pattern for blocks in polyForth where 3 blocks
would fit on one printed page. In the end, the shadow would also fit
with a smaller font. The index pages would just print the 1st 64
character line of each block and the convention to put a revision date
at the end of that line helped significantly.
I don't remember the tool that Elizabeth mentioned, but I remember many
manual comparisons. Since most systems filled their available block
ranges, having two sets of blocks online at the same time was rare.
The best we could usually do was to compare the printouts.
Since most revision control systems assume that there are a combination
of pieces that need to be put together and most block based systems
assume that there are only one set of blocks, which typically fit onto
a floppy, there was not much effort put into tools to manage the source
base. It's not that the need wasn't there, but the mind set was
different.
The sneaker net worked!
DaR
| 
