Unable to clone huge repository with large files #1525
Comments
|
It looks like there is some mercurial command on the wire which we don't understand. Do you use any mercurial extensions on the client or on the server, which are modifying the clone behaviour? |
|
Here are server-side extensions: Here are client-side extensions: The client hangs on this stage: And here is the same clone when repo is served via Client hung without clonebundles servier-side extension as well. |
|
A few other notes:
The very last part of the long request looks suspiciously: |
|
Well, if we look at the log attached, all x-hgarg requests are truncated which makes me think that it is Mercurial logging just intentionally truncate them before printing to stdout. BTW, the default config has the following: What is the reason, if |
|
Ok, it looks like there is a problem with the
The increase of the header size is for older mercurial versions, which are using http headers to transfer information about the head of the repository and if you have many heads then you need a large buffer for the headers.
No.
Most of what the SCM-Manager does during a clone is handling authorization, the rest is pipeing the client request from the web to a forked mercurial process. It gets more interesting if we talk about push. But what exactly do you want to know? |
Just trying to help to identify the root cause of the issue. Just curious, if vanilla I managed to make it to work doing the following: server-config.xml: Mercurial.ini: I've also noticed a separate option for Mercurial Configuration in SCM Manager: |
|
I've done some more research and the newest versions of mercurial still use http headers for the http command protocol. It looks like the largefiles plugin uses the same mechanism for its files. This is probably the reason, why you need such a large header size for jetty. The |
But that doesn't explain why everything works with vanilla |
|
I'm not sure if |
Fixes a regression which was introduced with #1416. In #1416 we have reimplemented the way configuration is passed to the mercurial cgi handler. Before #1416 we used environment variables which are picked up by hgweb.py, after #1416 we pass mercurial configurations as command line parameters directly in the HgCGIServlet. But sadly the configuration option for httppostargs uses still an environment variable, which is not picked up by anyone. See #1525
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
stale
bot
added
the
stale
stale
bot
removed
the
stale
Issue description
We have pretty huge repository with large files. And now we are unable to clone the entire repo. Mercurial client hangs.
Describe how to reproduce the bug
Mercurial client hangs if we clone repo via SCM Manager:
hg clone https://scm-server/scm/repo/hg/my-repoEverything works as expected if we serve repo using
hg serveand clone it usinghg cone http://scm-server:8000 my-repoDescribe your SCM-Manager setup
SCM Manager version 2.13.0 on Windows
Mercurial version 5.6.1
No special setup except for HTTPS.
Which operating system, browser and versions do you use?
Operating system doesn't matter: same behavior on Windows and Linux.
Log of the bug
Full error log and config are attached.
scm-server.err.log
server-config.xml.txt
When Mercurial client hangs, SCM Manager error log contains one of the following records about exception:
or
The text was updated successfully, but these errors were encountered: