Re: [PATCH rebase 0/2] Avoid unncessary rebases

2018-02-13 Thread Achim Gratz
Jon Turney writes:
> But (i) we still read and extract the ImageBase out of every DLL in
> the database, in case it's changed,

I think that's how it should be.  When you run rebase, you must consider
that something changed behind your back and fix it up or the users will
go mad.

> and (ii) rebaselst from autorebase seems to pass in a list of every
> DLL, not just the ones which have been added/removed by packaging
> changes, so I'm not entirely sure this is working as intended, or as
> well as it could...

Huh?  No, it shouldn't do that, the whole point of incremental rebase is
to only feed in those files we know have changed.  But it's very much
intentional that the files we _assume_ to be unchanged get checked by
rebase if that's true.  If you want to suss it out, look at the files in
/var/cache/rebase (these are from the latest run and the one before that
with suffix .old) and in /var/log/setup.log.full (I've made rebase
pretty verbose so one should be able to see where a problem occured just
from the log).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs


Re: [PATCH rebase 0/2] Avoid unncessary rebases

2018-02-13 Thread Jon Turney

On 09/02/2018 11:59, Jon Turney wrote:

Add some dignostics which report why a rebase is taking place.

Use that information to fix some errors causing unnecessary rebases



After these fixes, 'rebase -s' is relatively quick, with a warm disk cache.

But (i) we still read and extract the ImageBase out of every DLL in the 
database, in case it's changed, and (ii) rebaselst from autorebase seems 
to pass in a list of every DLL, not just the ones which have been 
added/removed by packaging changes, so I'm not entirely sure this is 
working as intended, or as well as it could...