setup.exe rebase patch

[Robert Collins]

> -----Original Message-----
> From: Jason Tishler [mailto:jason@tishler.net] 

> > Yes. I think that setup.exe based rebasing should be optional, but 
> > default to on. A flag in rebase.conf to control this would be good, 
> > along with a dialogue box and a tick :]. Not needed for the initial 
> > merge though.
> 
> OK, sounds good.  I'm not a GUI guy -- I hope that Gary will 
> come to my rescue. :,)

Ok, well lets get it into head, Gui can come later. (I can GUI too :}).
 
> > > I haven't tried LoadLibrary(), etc. but I presume that one of the 
> > > APIs can.  However, isn't this too little, too late?  
> What can we do 
> > > when the corruption occurs?  Rollback to the copy in the archive? 
> > > But, then this image will *not* be rebased. :,(
> > 
> > I was thinking of the following process (for all dlls we attempt to
> > rebase):
> > 0) Check that it hasn't been rebased already.
> 
> What is the purpose of the above?  I already rebase DLLs into 
> their previous space during reinstalls, if they still fit.

Efficiency, it seemed obvious to not rebase already rebased .dll's. I recall you saying that it was fast, but I don't see it scaling to 100's of .dll's - which we are heading towards.
 
> > 1) Copy
> > 2) Rebase
> > 3) Check for corruption - mark as occupying it's own prior space if 
> > corrupt and then stop, otherwise mark it's new space in the 
> used list.
> 
> What happens when the prior space is already taken?

Good point. If the prior space is taken by a non-rebasable .dll (another thing to record :}) then spit and error, otherwise, shuffle that dll to the next free slot.
 

> Is the "complete list" approach above required for the first 
> iteration?

No. TODO lists are good. Give you something to do :}.
 
> > Ah. Well within setup io_stream is the answer as they
> 
> Huh?  You didn't finish the above sentence.

Something about, not sure what to do for non-setup version, perhaps link in appropriate .o's.
 
> > What feels procedural is separate classes for 
> serialisation. I _feel_ 
> > (And can there for be told to get my nose out of it) that a better 
> > encapsulation would be for the used list and free list to have 
> > [de]serialisation capability, and the config_file class to 
> shrink to 
> > simply finding the config file, identifying the beginning 
> of (say) a 
> > used list section, and then passing the buck. Would you care to 
> > comment on this as opposed to your current model?
> 
> Ah, I see your point.  I guess that it depends on how you 
> want to slice and dice.  I have used the load/save paradigm 
> many times before and in general prefer it.  However, in this 
> case I don't quite think of the config file data as object 
> state.  What happens if there are syntax errors, etc.?  I 
> think that a config file object should deal with these kinds 
> of issues (although is could delegate some of the 
> responsibility to the list objects).  Additionally, with my 
> current approach I can change the config file format without 
> affecting the list classes.

But you can't change the list classes (ie add a new mandatory constructor parameter) without breaking the serialisation classes. I think you want the Memento pattern for this.
 
> Nevertheless, if you feel strongly, then I will change my perspective.

It's not about feeling. It's about understanding. I agree that having the serialisation in the classes themselves is not great, as things get baggy. I hope that you agree that having external classes that require access to private data (ie config_file_writer) for serialisation is also not great because it breaks encapsulation (friends don't always break encapsulation, but in this case, IMO they do). The Memento class is designed to provide a solution to both issues.
 
> > I'm suggesting I get my stuff out of your way :}. Your code seems 
> > traditional list based, which mine isn't (anymore), so your 
> code could 
> > generalise to be a list/map template.
> 
> OK, sounds good.

I'll organise this shortly, and let you know when I do it. (After setup200202 gets into production).

Rob