At 10:37 27.07.2006, Marcus (?) wrote:
>>My goal:
>>
>>1) In order to research fixes to bugs in squeak I
>>would like to have easy access to the version history
>>of changed methods. The images with all changes from
>>3.0 thru xxxx along with the changes in the current
>>image of 3.9 have been my main tools in doing that
>>research.

Our updating scheme in the OOram project may be of interest here. (The code 
was in VW):

1)
Major releases where named by a single letter. A basic release started its 
life with condensed sources in source file 1. The main change file (source 
file 2) was empty.
2)
Intermediate releases were named with sequence numbers, e.g., G8. The 
changes from the major release were in a source file number 2.
3)
Individual programmers copied the current release with its two read-only 
source files and added a sources file number 3 to hold his or her private 
changes. (I found it impractical to add a third source file in Squeak; a 
great pity)

My current image (I'm still playing with it from time to time. Source no. 1 
is 25MB, no. 2 is 7MB, no. 3 (my personal, g09-trygve.st, is 17MB)

Every method source has a header of change notifications, e.g.,
     " 920317 trygve(4.0): Use Cursor execute, not wait. "
     " 19990125 pst (g09-1): Moved from 'end:' to be shared with subclasses. "
     " 19990125 pst (g09-1): Superfluous 'end' removed from last page. "
A designated "releasebuilder" collected all contributions. Software checked 
the date sequences  for submitted methods. Branches in the modification 
tree indicated conflicts and could be detected easily.  This worked well 
for us in our closed community of less than a dozen programmers. ctrW 
created a comment line with date and signature. The cursor left in a 
position for writing additional comment. (Laziness is the mother of invention)

There has been discussions about adding extra info to the methods. One 
candidate is the method's life history, automating the discipline required 
by the OOram scheme. An entry could be added automatically at each compile, 
giving the date, release name and author name. Compression of the entry 
list could be automatic at submission time. The programmer could also be 
invited to add a final comment at this time. Harvesters could esily find 
conflicts between submissions.

cheers
--Trygve




-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway