[PATCH 1 of 6 V2] obsstore: add a 'cachekey' method

[Pierre-Yves David]

On 06/06/2017 12:02 AM, Martin von Zweigbergk wrote:
> On Sat, May 20, 2017 at 8:30 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at octobus.net>
>> # Date 1495191830 -7200
>> #      Fri May 19 13:03:50 2017 +0200
>> # Node ID 221be1ef98902fa695a709371f75e63f9b3e950a
>> # Parent  566cfe9cbbb9b163bb58c8666759a634badacdd7
>> # 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 221be1ef9890
>> obsstore: add a 'cachekey' method
>>
>> Parsing the full obsstore is slow, so cache that depends on obsstore content
>> wants a way to know if the obsstore changed, and it this change was append only.
>>
>> For this purpose we introduce an official cachekey for the obsstore. This cache
>> key work in a way similar to the '(tiprev, tipnode)' pair used for the
>> changelog. We use the size of the obsstore file and the hash of its tail. That
>> way, we can check if the obsstore grew and if the content we knew is still
>> present in the obsstore.
>
> Jun suggested to me personally that we could use a UUID and the size
> as a cache key. The UUID would be replaced only when the file was
> stripped. It could be stored inside a fake obsmarker as the first
> obsmarker in the file. That sounds like a good idea to me. What do you
> think?

We can't guarantee old clients doing strip will update that UID.
In addition, this breaks the happen-onlyness of the obsstore. Rollback 
would also no longer be able to just retract the file size to perform 
its duty.

So this approach will not work :-/

The currently used cache key (size + hash of last bits) is not perfect, 
but works fine so far. Is there specific concerns about it?

> We could do the same for the changelog, but that would require a new
> format and requirement, so that's a much bigger change.

In short same apply to the obsstore. we need a format change to 
introduce an integrated cachekey.

Actually, I'm hope to take advantage of greg next changelog format to 
sneak a more solid cache key in there.

Cheers,

-- 
Pierre-Yves David