Occasional http 500 (KeyError) errors on clone/pull/push

[Matt Mackall]

On Mon, 2013-12-02 at 14:27 -0700, Bruce Cran wrote:
> On 12/2/2013 1:48 PM, Bruce Cran wrote:
>  > Since no changes were found, they should have been skipped - but for 
> some reason it aborts instead.
> 
> This sounds like http://bz.selenic.com/show_bug.cgi?id=3781 (fixed in 2.5):
> 
> "It is possible to reference read-only repository as subrepo. Push in a 
> super repo recursively push subrepo. Those pushes to potential read only 
> repo are not optional, they are "suffered" not "choosed". This does not 
> break because as the repo is untouched the push is supposed to be empty. 
> If the reference repo locally contains draft changesets, a courtesy push 
> is triggered to turn them public. As the repo is read only, the push 
> fails (after possible prompt asking for credential). Failure of the 
> sub-push aborts the whole subrepo push."

No, it's actually this from 2.4:

http://www.selenic.com/hg/rev/59a168019255

Your 2.2 client has _always_ been attempting to push. What's changed is
that the server is now reporting "ssl required" more correctly, which is
causing the client to properly abort rather than silently move on. That,
in turn, is breaking your (slightly questionable) configuration. Oops.

Three possible fixes:

- point your subrepos at https urls
- turn off the SSL requirement on your internal repos
- upgrade clients to 2.6 or better

In 2.6, we locally keep a 'clean' flag and don't even talk to the server
on push if nothing's changed, which should improve performance
significantly.

We probably can't roll back the SSL error reporting change at this
point, so nothing to do on our end.

-- 
Mathematics is the supreme nostalgia of our time.