Avoiding excessive compiling after a rebase

Kevin Bullock kbullock+mercurial at ringworld.org
Thu Jun 16 11:15:43 CDT 2011


On Jun 15, 2011, at 7:10 PM, John Jefferies wrote:

> 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.

Whether _you_ care about nanosecond resolution or not is unfortunately irrelevant... if hg 'restores' a timestamp on a file a few nanoseconds off, you'll still have to rebuild it.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock



More information about the Mercurial mailing list