[PATCH 2 of 8] transaction: track newly introduced revisions

[Pierre-Yves David]

On 05/03/2017 10:09 AM, Jun Wu wrote:
> Excerpts from Pierre-Yves David's message of 2017-05-03 01:43:39 +0200:
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
>> # Date 1493743551 -7200
>> #      Tue May 02 18:45:51 2017 +0200
>> # Branch stable
>> # Node ID 76a035851a620dcf36a6dd18a37409dff43c6d42
>> # Parent  6697da7c4eab3fbe3588a2f91fa3f99b16f808ac
>> # EXP-Topic obscache
>> # Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
>> #              hg pull https://www.mercurial-scm.org/repo/users/marmoute/mercurial/  -r 76a035851a62
>> transaction: track newly introduced revisions
>>
>> Tracking revisions is not the data that will unlock the most new capability.
>> However, they are the simplest thing to track and still unlock some nice
>> improvements in regard with caching.
>>
>> We plug ourself at the changelog level to make sure we do not miss any revision
>> additions.
>>
>> The 'revs' set is configured at the repository level because the transaction
>> itself does not needs to know that much about the business logic.
>>
>> diff --git a/mercurial/changelog.py b/mercurial/changelog.py
>> --- a/mercurial/changelog.py
>> +++ b/mercurial/changelog.py
>> @@ -535,3 +535,14 @@ class changelog(revlog.revlog):
>>          just to access this is costly."""
>>          extra = self.read(rev)[5]
>>          return encoding.tolocal(extra.get("branch")), 'close' in extra
>> +
>> +    def _addrevision(self, node, rawtext, transaction, *args, **kwargs):
>> +        # overlay over the standard revlog._addrevision to track the new
>> +        # revision on the transaction.
>> +        rev = len(self)
>> +        node = super(changelog, self)._addrevision(node, rawtext, transaction,
>> +                                                   *args, **kwargs)
>> +        revs = transaction.changes.get('revs')
>> +        if revs is not None:
>> +            revs.add(rev)
>
> Since changelog is append-only, and strip won't happen during a transaction.
> Why not just record len(changelog) during transaction start, and test
> len(changelog) at the end of transaction?

Mostly for simplicity, having the pure raw information on the 
transaction is simple and cheap. And it gives us access to all kind of 
native operation directly (len, membership, iteration) without the needs 
to perform the same (simple) operation all over the place. It also allow 
user code to operation without having a changelog object, another small win.

User-code in this series are fairly simple, but we'll have smarter and 
smarter usage of these data as more code uses it.

I'm not worried about the memory usage since many other place assumes we 
can keep all repository revs in memory.

> That's O(1), instead of O(N log N)

(note: I'm not sure what type of complexity you refer to, nor what is 
the operation you are considering to get theses number)

Cheers,

-- 
Pierre-Yves David