Avoiding excessive compiling after a rebase

[John Jefferies]

On 15/06/2011 22:15, Matt Mackall wrote:
> On Wed, 2011-06-15 at 11:06 +0100, John Jefferies wrote:
>> I like using the rebase feature. In particular, I'm rebasing applied MQ
>> patches after pulling from the central repo.
>>
>> This workflow does suffer one flaw (from my PoV) in that in my usage,
>> the rebased files are all rewritten to disk. This has the conseqence of
>> needing to rebuild these files, even though much of the time the rebased
>> files haven't been merged during the rebase. My rebuild time can be
>> significant, 10 minutes or more if a rebased header has many
>> dependencies. And multiple configurations will require more again.
> That's quite ugly, architecturally. "Restoring" timestamps is a
> tricky/sneaky business, and... it's actually basically impossible to do
> right in Python on systems with nanosecond timestamps (Python floats
> don't have the requisite resolution!).
>
> I'd consider something like this at the level of individual file merges
> (ie avoiding touching a file altogether if a merge ended up being a
> no-op). But for rebase, we're actually doing a chain of operations that
> involve checking out other revisions. Short of mirror-imaging the rebase
> process so that the rebased csets were 'local' (and thus flipping the
> named branch logic, ouch), there's no clean way to do this.
>
>
> If you can, I'd recommend using something like ccache:
>
> http://ccache.samba.org/

Thankyou for considering the problem. The ccache solution won't work for 
me because it's GCC only and I don't really have the option of switching 
to it for most of my work.

For this purpose, I don't really care about nanosecond timestamps, the 
nearest minute would do. I'll see what I can come up with on a spare 
Friday afternoon.

J