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

[Martin von Zweigbergk]

On Tue, Jun 6, 2017 at 11:04 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> 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.

There are old clients that strip the obsstore? I thought that was a new feature.

> In addition, this breaks the happen-onlyness of the obsstore.

What depends on the append-onlyness?

> Rollback would
> also no longer be able to just retract the file size to perform its duty.

Good point.

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