I’ve set up a number of Mercurial repositories that certain users are configured to have read-only access to (via the READ role).
These users have no problems cloning the repositories but if they do a pull they get a Forbidden 403 error.
Here’s an example where I clone from the Windows command line and then do an immediate pull.
V:\>hg clone --verbose https://username@my.server.address/scm/repo/demo/repo "V:\demo1"
requesting all changes
adding changesets
adding manifests
adding file changes
added 57 changesets with 1888 changes to 1605 files (+1 heads)
66 new obsolescence markers
new changesets 272ea1d84230:7ad3f7794298
updating to branch default
resolving manifests
calling hook preupdate.eol: hgext.eol.preupdate
getting .hgflow
getting .hgignore
getting .hgtags
----
SNIP
----
1597 files updated, 0 files merged, 0 files removed, 0 files unresolved
(sent 4 HTTP requests and 1771 bytes; received 4066849 bytes in responses)
V:\>cd demo1
V:\demo1>hg pull -v
pulling from https://username@my.server.address/scm/repo/demo/repo
searching for changes
no changes found
(sent 4 HTTP requests and 6305 bytes; received 649 bytes in responses)
abort: HTTP Error 403: Forbidden
I’m using the latest 2.24 SCM-Manager on a Windows Server 2019 box behind an IIS reverse proxy. It’s using the Mercurial executable of a TortoiseHg instance on the same machine.
If I give these users the WRITE role then they have no problems doing a pull from these repositories.
Hi @lachlang ,
can you please repeat your pull call with the debug flag?
hg pull --debug
And can you give us trace logs from the server (these can be created easily using the support plugin)?
This forum only allows uploads of images so I’m not sure how you want me to submit the full logs and stack traces. I’d prefer to submit them via a non-public method regardless.
I believe the problem is because I make use of the Mercurial evolve/changeset evolution feature. It appears that even immediately after a clone, the pull operation wants to send back evolve related metadata.
Here’s the same output as before but using the debug flag as requested.
V:\>hg clone --verbose https://Lachlan@my.server.address/scm/repo/demo/repo "V:\demo2"
requesting all changes
adding changesets
adding manifests
adding file changes
added 57 changesets with 1888 changes to 1605 files (+1 heads)
66 new obsolescence markers
new changesets 272ea1d84230:7ad3f7794298
updating to branch default
resolving manifests
calling hook preupdate.eol: hgext.eol.preupdate
getting .hgflow
getting .hgignore
getting .hgtags
----
SNIP
----
1597 files updated, 0 files merged, 0 files removed, 0 files unresolved
(sent 4 HTTP requests and 1879 bytes; received 4066849 bytes in responses)
V:\>cd demo2
V:\demo2>hg pull --debug
pulling from https://Lachlan@my.server.address/scm/repo/demo/repo
using https://Lachlan@my.server.address/scm/repo/demo/repo
http auth: user Lachlan, password not set
sending capabilities command
keyring: base url: https://my.server.address/scm/repo/demo/repo, url user: , url pwd:
keyring: Checking for hgrc info about url https://my.server.address/scm/repo/demo/repo, user Lachlan
keyring: Password url: https://my.server.address/scm/repo/demo/repo, user: Lachlan, password: (prefix: None)
keyring: looking for password (user Lachlan, url https://my.server.address/scm/repo/demo/repo)
keyring: Password found in keyring
query 1; heads
sending batch command
searching for changes
all remote heads known locally
no changes found
query 0; add more sample (target 100, current 2)
query 0; sample size is 100, largest range 53
sending evoext_obshashrange_v1 command
(sent 4 HTTP requests and 6413 bytes; received 649 bytes in responses)
We used to do this fine with BitBucket prior to them shutting down their Mercurial support. They supported changeset evolution and you could set those repositories to be read-only for some users.
It looks like we’ve got to dig further for this. We will check soon, what we can about this and come back to you.
Hey @lachlang,
sorry it took us so long to dig deeper into this issue. We actually managed to fix it. The fixed version should be available with our next release.
Regards, Eduard