> On 2022-11-25, at 11:28 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Hi David,
> 
>    this seems backwards to me.  It seems to me that one would want to cache the sources but keep the changes gfile for crash recovery.  Sicne the changes file should mbe empty at the start of a release this would mean that all sources were cached.  What am I getting wrong?  

Generally we don't condense sources for most releases, so the changes does tend to be around. The 5.3 release changes was ~18Mb for example.


> And how does your scheme do crash recovery, if at all?

I don't think this version of Dave's idea does, which is certainly something I'd like to see. Having the changes 'file' cached in-image is fine but having at least an option to make it write-through to an outside destination would be good. There's a lot of different ways we could do this.

Last time I tried a similar approach I made the source pointer stuff be an object that could be a Smallint to point into a file or a String or a link of some sort to something I don't even remember. That meant you could mix'n'match where source came from, which seemed plausibly interesting. You might even make it go via a web service that serves up the source and stores new source & doits in a shareable manner, merging in with some monticello capabilities.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Oxymorons: New classic