On 15 December 2010 19:30, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Dec 15, 2010 at 5:23 AM, Peter van Rooijen <peter@vanrooijen.com> wrote:
On Fri, 10 Dec 2010 21:11:47 +0100, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Note that not writing source to the changes file has ancilliary benefits; change recovery is now not polluted with package loads and the changes file does not grow as packages are added, only as one's changes are made. Unloading a package doesn't leave garbage in the changes files.
There are downsides. Â Deploying a development image means deploying all the associated parcel source files as well, and for this a platform-independent Filename abstraction really helps.
Thanks for the explanation. I wonder how the previous versions of a method can be found using parcels.
I hacked a dreadful implementation of overrides in vw3.0 and I don't think things are much better now.  But in http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg17714.htm... I sketched how I think it should be done: Maintain a global package load order (a stack of loaded packages, removing interior elements on unload). Maintain a dictionary from method reference to set of package/method pairs for each method that is overridden. When a package is removed search overrides and compute the overridden methods to be reinstalled, computing the uppermost method depending on the new package order. So to answer your question, one finds the previous versions directly in the overrides dictionary, and sorts the results according to the current package load order.
Wasn't Levente asking about "regular" replacing of methods?
I thought his question was about that; if the source is not in
the changes file but in a parcel source file, then when I save
a new version of a method and want to look for the old one,
that will not be in the changes file.
No. Â Anything you write goes on the changes files including new method definitions, doits, reorganizations, method removals class removals etc.
When I build up a new image
from parcels, the load script copies all the sources to the
changes file, so I have easy access to the history.
Why bother? Â A published parcel is an immutable versioned artifact. Â It doesn't change over time, so, like a release sources file, one can always rely on its contents.
+1 Instead of putting all methods and classes from package into .changes it could be just a simple doit, like: MC load: 'blahblah.mcz' It could be somewhat different during merge.
HTH Eliot
-- Best regards, Igor Stasenko AKA sig.