At 10:37 27.07.2006, Marcus (?) wrote:
My goal:
- 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