On Sat, 29 Jul 2006 08:42:09 +0200, Peace Jerome wrote:
...
> The important thing is to be able to find (in one
> image or another ) the versions that lead up to the
> current one. And to get the most information out of
> them as to what changed; by whom; and to infer for
> what purpose.

I doubt that this can be achieved, at least not with the current tools  
(and .image). Simple counterexample: a method which is no longer active in  
the image is an orphan in the .sources or the .changes file. Only if the  
corresponding ChangeRecord instance is still in the image and accessible  
by a tool, then you'd be able to access it for your investigation.

Example for an orphan in .source : ThreePhaseButtonMorph methodsFor:  
'geometry' stamp: 'tk 7/1/97 09:14' #extent. This method is no longer in  
the image (was probably not distributed with a change set).

Example for an orphan in .changes : ChangeListPlus methodsFor: 'viewing  
acces' stamp: 'ar 7/15/2005 13:53' #diffedVersionContents. This method has  
two other change records, one of which should have "prior:" pointing to  
the orphan.

Attached is a script which does the following (with #7048):

1 - read all chunks from .sources and note the preamble and chunk position
2 - read all chunks from .changes and note the preamble and chunk position

This is done for class definitions (they have no preamble so the chunk  
position is taken to be := the preamble position), for class comments  
(have preambles) and for methods (have preambles). Then in a second stage  
the following is matched against the above:

3 - obtain all class comment ChangeRecords via the existing  
#scanVersionsOf: routine
4 - obtain all method ChangeRecords via the existing #changeRecordsAt:  
routine

(both routines are the exclusive methods used by browsers which need  
version information). This second stage information then overwrites the  
information obtained during the first stage, by fileIndex and filePosition  
of their sourcePointer, so that the result tells which items are linked by  
regular historical "prior:" pointers and which are not.

So when an item from steps 1-2 is not matched during steps 3-4, it must be  
an orphan.

The script allocates a new global variable SourcesAndChangesPointers by  
which the results can be accessed (and .image can be saved and analyzed  
later).

(SourcesAndChangesPointers first) are the results for the .sources file,  
(SourcesAndChangesPointers second) are the results for the .changes file.  
Both collections are instances of IdentityDiectionary.

Some datapoints obtained so far:

SourcesAndChangesPointers first size 33979 "# of non-doIt chunks (items)  
in .sources"

(SourcesAndChangesPointers first associations select: [:assoc | assoc  
value isInteger and: [assoc key ~= assoc value]]) size 13840 "# of items  
not covered by ChangeRecord routines"

(SourcesAndChangesPointers first associations select: [:assoc | assoc key  
== assoc value]) size 1509 "# of class definitions found in .sources"

(SourcesAndChangesPointers first associations reject: [:assoc | assoc  
value isInteger]) size 18630 "# of items covered by ChangeRecord routines,  
in .sources"

SourcesAndChangesPointers second size 55200 "# of non-doIt chunks (items)  
in .changes"

(SourcesAndChangesPointers second associations select: [:assoc | assoc  
value isInteger and: [assoc key ~= assoc value]]) size 11997 "# of items  
not covered by ChangeRecord routines"

(SourcesAndChangesPointers second associations select: [:assoc | assoc key  
== assoc value]) size 170 "# of class definitions found in .changes"

(SourcesAndChangesPointers second associations reject: [:assoc | assoc  
value isInteger]) size 43033 "# of items covered by ChangeRecord routines,  
in .changes"

The condition "assoc value isInteger and: [assoc key ~= assoc value]"  
denotes an item which wasn't assigned a ChangeRecord by some root in the  
image (root = class comment sourcePointer or method sourcePointer), taking  
into account all their possible history items, as computed by the  
respective routine (mentioned above). The condition "assoc key == assoc  
value" denotes class definitions found during the first stage (they have  
no source pointer in the current incarnation of the source code  
subsystem). And the exclusion "assoc value isInteger" denotes items with  
regular ChangeRecords (possible linked in history with "prior:").

More scripts could be written (but then SourcesAndChangesPointers must  
become a class), for example for the visualization of orphans and for  
viewing selections/subsets of the ChangeRecord items by using existing  
tools, like VersionsBrowser.

Disclaimer: it was carefully tested but the script may contain bugs.

>>> And that it is not missing any vital historical
>>> information.

Yes, that'd be great!

/Klaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SourcesAndChangesPointers.st
Type: application/octet-stream
Size: 4661 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060729/739e4c95/SourcesAndChangesPointers.obj