Squeak Maintainence and etc. ; Problem restatement.
Klaus D. Witzel
klaus.witzel at cobss.com
Sun Jul 30 02:37:13 UTC 2006
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
>
>
More information about the Squeak-dev
mailing list
|