[PATCH 6 of 8] obsolete: exchange obsolete marker over pushkey

Idan Kamara idankk86 at gmail.com
Fri Jun 8 04:50:56 CDT 2012


On Thu, Jun 7, 2012 at 8:56 PM, Patrick Mézard <patrick at mezard.eu> wrote:
>
> Le 07/06/12 19:24, pierre-yves.david at logilab.fr a écrit :
> > # HG changeset patch
> > # User Pierre-Yves.David at ens-lyon.org
> > # Date 1339089719 -7200
> > # Node ID e1d9043377d43a41c37f086aadfbe0552854c29a
> > # Parent  740baee7f4950cb25ef79fa0782c1b8dfe8ffb92
> > obsolete: exchange obsolete marker over pushkey
> >
> > For a version of the exchange, all markers are exchange. This won't
> > scale and we will need a better protocol later.
>
> To elaborate a bit, there are 2 flavours of "won't scale":
> - The obvious exchange everything all the time
> - The less obvious exchange everything all the time *with pushkey*. Over
> HTTP, pushkey sends all the data in split HTTP headers, which easily
exceeds
> both Apache default max header count (100). It is hard to provide numbers
> about the store size because the current obsolete/evolve extension uses
> another JSON base format which is much more verbose than this one, and
> because Pierre-Yves experimental mercurial evolving repository underwent
> several format upgrades which messed up the store, but right now it is
> around 2.2M for 5500 markers. To summarize, it is easy to reach a
situation
> where the HTTP servers/proxies cannot handle the pushkey load. I do not
> think this is a problem unless people believe "won't scale" applies to
> Bryan-sized repositories. Note that you can work around this limitation
with
> SSH.

This is interesting and I feel a pretty important aspect of the feature.

A few questions:

1) does the 'obsstore' ever shrink or does it grow indefinitely?
2) when I pull from someone, am I getting his entire 'obsstore' or just
the bits I'm interested in?
3) how is conflict resolution handled (or will be in the future)?
4) have you considered using a revlog as the storage model?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120608/8006c455/attachment.html>


More information about the Mercurial-devel mailing list