[PATCH 1 of 6 path intent] ui: add an intent to expandpath
pierre-yves.david at ens-lyon.org
Fri Oct 17 20:37:04 CDT 2014
On 10/17/2014 05:41 PM, Gregory Szorc wrote:
> On 10/17/2014 1:59 PM, Pierre-Yves David wrote:
>> On 09/29/2014 05:30 PM, Gregory Szorc wrote:
>>> To further complicate matters, our HTTP layer is currently rejecting
>>> some Mercurial HTTP requests because the encoding of 100+ heads during
>>> discovery is exceeding HTTP header limits. We have some workarounds to
>>> use SSH instead of HTTP for discovery, when appropriate.
>> I would have appreciated a proper report for this bug on our bug tracker
>> month ago. It would have given a chance to spot and fix it before the
>> interaction of buggy discovery and filtered changesets blow in face this
>> morning ☹
>> We need Mozilla to report bugs. As a side effect it may help Mozilla to
>> see their bug fixed. ☺
> It's an inherent limitation in how Mercurial has done discovery for ages
> and AFAIK has nothing to do with filtered changesets. If you found a
> bug, it was by coincidence :) Mozilla's specific problem could be
> remedied if we increased limits on our HTTP servers: Mozilla is
> footgunning ourselves. But there *is* room for discovery to be more
since 1.9 (2011) Mercurial is supposed to use a smarted discovery
algorithm that is able to limit the number of changesets it ask about.
One of the goal not break every on super headed repo. However this limit
is ignored for some part of the discovery and this is why it break. I
classify this as a bug. The filtering is involved here because using
evolve made my repo superheaded (from an unfiltered perspective).
> I previously tried to start a conversation about it ,
> but it didn't seem to go much of anywhere.
I'm sorry we missed that. A real bug report with test with modern
Mercurial would have helped to catch it up.
More information about the Mercurial-devel