caching pull - stable partitioning of bundle requests

Pulkit Goyal 7895pulkit at gmail.com
Fri Feb 15 15:16:10 EST 2019


On Thu, Oct 4, 2018 at 6:16 PM Boris FELD <lothiraldan at gmail.com> wrote:

> The road for moving this in Core is clear, but not short. So far we have
> not been able to free the necessary time to do it. Between the
> paying-client work, we have to do to pay salaries (and keep users happy)
> and all the time we are already investing in the community, we are already
> fairly busy.
>
> In early 2017, Bitbucket gave $13, 500 to the Mercurial project to be
> spent to help evolution to move forward. As far as we know, this money is
> still unspent. Since stable range is a critical part of obsmarkers
> discovery, unlocking this money to be spent on upstreaming stable range
> would be a good idea (and fits its initial purposes). Paying for this kind
> of work will reduce the contention with client work and help us, or others,
> to dedicate time for it sooner than later.
>

I definitely agree that obsmarker discovery is a critical part. Pulling
from `hg-committed` is slower sometimes as compared to pulling on a repo
(5-7x size of hg-committed) with server having thousands of heads.

Do you have any updates on the stable-range cache? In the current state the
cache is pretty big and a lot of people faced problem with the cache size.
Also in case of strip or some other commands, it rebuilts the cache which
takes more than 10 minutes on large repo which is definitely a bummer. Are
you working on making that better and take less size? How is
experimentation of evolve+stablerange going on?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190215/2a07d9b0/attachment.html>


More information about the Mercurial-devel mailing list