Stef, all, I doubt I will actually do this since I seem to have recovered things fairly well, but what do you think about the following proceedure:
(1) use most recent loadable image from a backup and the most recent available changes (which I already did) (2) condense changes (3) recover lost changes in the resulting image. If it does what I think/want it to do, I assume the redudant changes would be eliminated, making it easier to recover the most recent state of any given method. Does that sound right? Bill -----Original Message----- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, March 27, 2010 10:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Recovering lost changes On Mar 27, 2010, at 3:34 PM, Schwab,Wilhelm K wrote: > Stef, > > I just spent an hour or so using the lost changes browser to recover much of > the past couple of day's work. The good news is that it was very stable in > doing what it does. I have been doing a lot of code generation from meta > data, which allowed me to make a *very* large number of entries in the change > log. Sorting through that was problematic. Features of Ian Bartholomew's > Chunk Browser would have been very helpful. In particular, Ian offers ways > to filter on chunk type and to identify the most recent chunks for any given > class/method. > > My big mistake was failing to make a backup following the last generation > step and before importing more of my code from Dolphin. I have been using > SIF to export code followed by "search and replace" via the regex package to > create relatively cleanly loading code. Being forced to do that again, I > improved the search and replace step and found many relevant chunks that have > most of the imported code in reasonable shape; a lot of it will be buggy for > some time due to callbacks and other details. > > One thing that has been (temporarily) lost is some category changes, but that > will be easy to replicate. I am more concerned about subtle changes to the > generation that might not have survived the recovery. So far, it looks ok, > but my first priority was to get a post-recovery backup to avoid repeating > the whole mess. > > Now I notice that my change log is 29MB and climbing. Does #condenseChanges > work? It should. We use it for building the release candidates Now I thought that we do not have this limit but 2Gb > The limit is 32 MB, right? It might also simply be time to build a new > image on RC3. rebuilding fresh is always good. > > Bill > > > > -----Original Message----- > From: pharo-project-boun...@lists.gforge.inria.fr > [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of > Stéphane Ducasse > Sent: Saturday, March 27, 2010 7:12 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] Recovering lost changes > > > On Mar 27, 2010, at 4:09 AM, Schwab,Wilhelm K wrote: > >> Hello all, >> >> I had some type of melt-down today and ended up with an image that won't >> load. I have a backup from a few days ago, but a lot has happened since >> then. Recent change logs seem to be readable, but the "Recover lost >> changes" GUI has not been terribly helpful. Is there a way to filter to >> things like most recent versions of a any given methods, and/or sort on the >> types of chunks? >> >> One surprising weakness I noted was that many do-it chunks involve things >> that were in context in the debugger, are "now" nil and ended up breaking >> the file-in command. I put an error handler around the evaluatations which >> helped, but things are still somewhat slow thanks to other do-its that do a >> LOT of work. I might start chipping away from the most recent chunks until >> it recovers enough that I can cut my loses. >> >> Ian Bartholomew's Chunk Browser for Dolphin would be an ideal tool to >> emulate. With what we have now, any workarounds for the things above would >> be greatly appreciated. > > > we should already log class definition as class definition and not doits. > There are so many things to fix. > Cleaning the chunk format, fileouter, changes recorder... > >> Is there a way to do extended selection (e.g. shift-select to select a range >> of chunks)? >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
