[PATCH 1 of 5] transaction: change the on disk format for backupentries

Gregory Szorc gregory.szorc at gmail.com
Fri Nov 14 13:01:23 CST 2014

On 11/14/14 12:30 AM, Pierre-Yves David wrote:
> On 11/14/2014 06:08 AM, Gregory Szorc wrote:
>> On 11/13/14 3:39 PM, Pierre-Yves David wrote:
>>> # HG changeset patch
>>> # User Pierre-Yves David <pierre-yves.david at fb.com>
>>> # Date 1415152366 0
>>> #      Wed Nov 05 01:52:46 2014 +0000
>>> # Node ID dba745ba04b9bc614d422e2e88b362a3bbda6948
>>> # Parent  e44399c494ab23cefb8c99087529f9b4b06d398e
>>> transaction: change the on disk format for backupentries
>> So I guess we aren't going with the solution that was brainstormed at
>> the Munich sprint? (See "Transactions" in
>> https://titanpad.com/mercurial32-sprint)
>> Or are you going with an easy solution to transactions before the
>> complicated one (that will support reader locks)?
> I'm starting for a simple solution first. The complexe solution
> discussed at the munich sprint is "useless" if nobody is playing the
> transaction game. So I first need to consolidate our transaction logic
> to ensure basic property:
> - All contents written during the transaction is only made visible at
> the end of the transaction
> - All content written during the transaction is made available to hooks
> and hooks only right before we commit.
> - Any temporary file are properly cleaned up
> - Any file involved in properly backed up in case of error.
> Once I've this true, I can move to the next step: Change the format to
> ensure an atomic "write" of the data from a reader perspective. But I
> needs some to write atomically in the first place ;-)

Makes sense to me.

I am very excited about seeing these patches. As you may know, cache 
invalidation causing an expensive rebuild is a big problem for large 
repositories. We are seeing these expensive rebuilds occur after a 
pretxnchangegroup hook fails a push, for example. I can't wait to deploy 
3.3 at Mozilla!

Of course, we still see cache invalidation after strip operations. We'll 
need memctx everywhere, hidden changesets enabled by default, and people 
to stop using strip-based workflows (mq) before this is fully resolved, 
I fear. But this transaction work is refreshing nonetheless.

More information about the Mercurial-devel mailing list