[PATCH 1 of 6 path intent] ui: add an intent to expandpath

Pierre-Yves David 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
> intelligent.

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 [1],
> 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.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list