On 15 December 2010 19:30, Eliot Miranda <eliot.mira...@gmail.com> wrote: > > > On Wed, Dec 15, 2010 at 5:23 AM, Peter van Rooijen <pe...@vanrooijen.com> > wrote: >> >> On Fri, 10 Dec 2010 21:11:47 +0100, Eliot Miranda >> <eliot.mira...@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.html >> 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.
