I am getting issues with pushing to mercurial repository:

$ hg push

pushing to https://user:***@hg.domain.com/X_repo

trying to find changes

abort: authorization unsuccessful

Exactly the same URL (with similar qualifications) is obtainable with the internet browser. Also, I attempted it without embedding usr+pass in to the URL.

HTTPS is properly set up, I attempted both Fundamental and Digest auth -- with no luck.

Tugging (through HTTP) works fine.

I am using hgwebdir for everyone my repo.

What else must i check?

I discovered this: http://code.google.com/p/support/issues/detail?id=2580 During my situation it isn't random, it takes place each and every time.

Relevant a part of my vhost conf:

  WSGIScriptAlias  /  /home/(...)/hgwebdir.wsgi

  <Directory /home/(...)>

    AuthType Fundamental

    AuthUserFile /(...)/fundamental-password

    AuthName (...)

    Require valid-user

    Order deny,allow

    Allow all


$ hg -v

Mercurial Distributed SCM (version 1..2)

Oddly enough hg outgoing works ok:

$ hg outgoing

evaluating with https://hg.domain.com/X_repo

http authorization needed

realm: ...

user: ...


trying to find changes

changeset:   64:...

tag:         tip

user:        ...

date:        ...

summary:     ...

If any body wants to really make it operate on local machine than adding this to server REPO/.hg/hgrc is going to do the job:


allow_push = *

push_ssl = false

as descibed at this website.

Problem switched to be repo dir permissions. chown world wide web-data solved it...

It is strange that you could run hg outgoing although not hg push as it is my knowning that both of them authenticate in the same manner.

Regrettably I am not really a hgweb expert. Please write the Mercurial list (mercurial@selenic.com) and/or come online in IRC (#mercurial on irc.freenode.internet). You will see a lot more people that will help you there. IRC is particularly good as these situations are much simpler to debug interactively.

Just just in case it could help someone - I experienced this error for unknown reasons, all permissions were OK, and merely restarting apache solved it.