Are push times linear in the size of the repo?

[Pierre-Yves David]

On 04/14/2015 12:05 PM, Michael O'Connor wrote:
> I was looking at a breakdown of where the time was spent in pushing one
> empty changeset in a repo with a few hundred thousand changesets.
>
> It looks like there are a few places in the course of a push where some
> object is created that is linear in the total size of the repo (or the
> number of changesets in common between local and remote).  For example,
> in determining which changesets are outgoing (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/setdiscovery.py#l131),
> in determining which phase information to push (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/exchange.py#l144), and
> in determining information about obsolescence of future heads (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/discovery.py#l276).
>
> In the third case, a patch was recently accepted to only compute this
> set when the repo actually has an obsstore, but is there a plan to
> eventually make pushing more incremental and not depend on the entire
> repo, or is it thought that this won't be a problem?  Or perhaps I've
> misread the situation?

Nothing should be have a linear time, current situation with many small 
branches all unknown on one side will increase the number of round trip.

Obsolescence discovery and pushing are currently suboptimal. This is one 
of the reason why evolution is still experimental. There is concret plan 
to improve that to a point where is quick at any size.

-- 
Pierre-Yves David