[PATCH 1 of 6 V2] obsstore: add a 'cachekey' method
Sean Farley
sean at farley.io
Thu Jun 1 20:27:44 UTC 2017
Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
> On 06/01/2017 07:05 PM, Martin von Zweigbergk wrote:
>> On Thu, Jun 1, 2017 at 9:48 AM, Jun Wu <quark at fb.com> wrote:
>>> Excerpts from Pierre-Yves David's message of 2017-06-01 18:15:17 +0200:
>>>> On 05/20/2017 05:30 PM, Pierre-Yves David 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
>>>>
>>>> What is the status of this series. V2 has been on the list for over 10
>>>> days and I still see it in patchwork. How can I help having it move
>>>> forward. There are various other improvements stuck behind this series.
>>>
>>> I think V2 radixlink will be fast enough so this series look unnecessary.
>>>
>>> I think adding revision numbers to obsstore components is what we should
>>> avoid in design.
>>>
>>> Not to say this series has perf issues with huge repos.
>>
>> It looks like we need someone less biased than you two to decide which
>> (or both) of the series to take :-) I just need to find time to review
>> both of the series and see what I think (and then we'll continue
>> discussing, I guess). Or we could VC all three?
>
> Both series are complementary and useful. Obscache is very efficient for
> its purpose and the other one improve other aspect of evolution related
> computation. We already have many rev indexed caches so nothing really
> new here.
This was my thinking as well. Though, I'm not trying to muddy the waters
here.
> The potential scaling issue on large repository of the obscache are easy
> to overcome, I've a series fixing most of them already ready to be sent
> once that one is in.
Ah, are those online somewhere?
> I would be happy to join a VC to discuss this.
I might like to join but if the schedule doesn't work out, please move
ahead without me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170601/e0c64d1a/attachment.asc>
More information about the Mercurial-devel
mailing list