On Sat, 29 Jul 2006 18:16:57 +0200, Andreas Raab wrote:
> Klaus D. Witzel wrote:
>> 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).
>
> There may be. Here is a thought that I had for a long time now: Consider  
> that the change history is simply one logical huge file of change  
> records where the .sources and .changes are mere portions of the full  
> "Squeak source file" that logs all the changes that were ever done as  
> the system evolved to your version.

Yes, like a subset of all change records.

> Also consider that if we can describe the name of a *previous* changes  
> (sources) file and if we can describe where in that changes file the  
> previous change record for some code lives, then you could have a  
> situation where -in the condensed changes file of SqueakX.Y.changes- you  
> will find that the "previous version" of some method is to be found in  
> "SqueakX.Y-k.changes".

If the information about "prior:" where accurate, always recorded and  
reliable: yes, for sure.

> In which case, merely by dropping the appropriate changes file alongside  
> your install you'd have the ability to browse those previous versions -  
> going back all the way to Squeak1.0 if you have all those "chunks of the  
> logical sources of Squeak" (represented by the .changes files).

I have converted .sources and .changes to SQLite3 (either using multiple  
tables or using mutiple db files for different releases, have choice). All  
that is needed for completing this is the correct "prior:" information  
(which seems to be rotten, see my previous message on this).

BTW: text queries, i.e. " where sourceCode like  
'%convert:%from:%to:%using:%' " are easy and fast with SQLite3 :-) This  
example finds all senders and implementors (and perhaps a bit more, can be  
further filtered), regardless of whether the method is/was ever in a  
distributed .image or not.

IMHO the "local" system can have "prior:" as filePosition but when  
travelling this should be translated to "priorStamp:". Can someone confirm  
this is sufficient, other opinions and/or experience is appreciated.

> The (obvious) point being here that if we can keep the information where  
> previous versions ought to be located, it would be trivial to do a  
> condense changes for each new version - if you want history, install the  
> previous versions of Squeak alongside the current one and you got it.

That'd be easy, I agree.

> [Disclaimer: The above obviously doesn't deal with packages etc. where  
> due to the current snapshot-nature of Monticello history information is  
> not preserved. In other words: This doesn't work for package history.].

Similiar to what Trygve described, "external" packages deserve their own  
fileIndex (or db table or file). That's all about it. If the package  
maintainer does a change, the (packageFiles at: fileIndex) gets updated.  
If a package user does a change to a package, her/his own (changeFiles at:  
fileIndex) gets updated. Can, if someone cares, be replayed on updated  
packages.

Some support for collaborative work (feedback, unaccepted and accepted  
changes) would make this an acceptable and usable system, IMO. Very small,  
very subtle, very easy steps. Not a big bang.

/Klaus

> Cheers,
>    - Andreas
>
>