Kiln Timeout Issues While Pushing/Pulling/Cloning


Follow

Overview

The most common reason for Kiln timeouts while pushing/pulling/cloning files from a repository is related to big files that might take a long time to transfer.

You might also see the following errors:

  • When connecting to Kiln through Tortoisehg
    HTTP Error 500 (Internal Server Error) followed by [Code: 255].
    Or
    '<repository URL>' does not appear to be an hg repository

  • When trying to download the archive ZIP of the repository through the UI
    It seems Kiln has overheated a bit. Sorry about that! Our monitoring systems have noted the error but, if you continue having trouble, please contact Fog Creek Support. inline895726035.png

 

 


Solution

Pushing big files (bigger than 50 MB) to a repository is generally not recommended because big files will be slow to synchronize, leading to potential network timeouts.

It might happen, mostly in Dev Teams, where by mistake a big binary file gets into a repo folder (ex. wrong output folder configured for a build) which gets pushed to the server, making it impossible to sync again.

Check the following solutions for possible fixes.

 

 

Mercurial or GIT Compatible Versions

Make sure that the version of Mercurial or GIT is correct and compatible with Kiln. The most stable version is the one that is packed with the current build of Kiln Client and Tools.

 

 

Using .hgignore

Use the .hgignore file to exclude files that will not be processed or uploaded. Try to push a .hgignore file to exclude the files for the next revisions.

If you have setup .hgignore, the files listed there will only be ignored for the next commit. Previously tracked files will be there on the previous revisions. Previously tracked files will be there on the previous revisions. If this is your case, use the hg forget "set:hgignore() and not ignored()" commands. This will force your repository to forget the listed files.

 

 

Push/Pull/Clone Options to Try

 

Use SSH

We have found that using SSH to sync this kind of files is generally better than using HTTPS since the latest is prone to errors in the transfer. 

 

Use --uncompressed

One way to get clone working could be by including the "-uncompressed" option. This foregoes compressions and trades more network traffic for speed.

 

Use --chunked

Large pushes can use the "--chunked" operation to automatically break up the load and help avoid timeouts when pushing.

 

Use --rev

All of these operations can benefit from running them against a few changesets at a time. The "--rev xx" (xx denotes the number of revisions that will be pushed) option will clone/push/pull only that revision and its ancestors. By working with a subset of revisions at a time, the operation will complete faster, which may help avoid timeouts. You can refer to Kiln Failing to Import a Large Repository for more information.

 

Use Verbose and Debug flags for Logging

Attempt a pull/push/clone with debugging and verbose flags: hg <push/pull/clone> --verbose --debug <url> and return the logs. Use the information from the logs to find the root cause.

 

 

Remove the Big Files from the History

The best thing to do is to remove those binary files from history. If they are recent changesets, you may be able to get away with replaying the recent changes without the binary files onto the last clean changeset.

 

 

Convert the repository with a filemap

Convert the repository with a filemap that excludes the offending binary files using the instructions from Mercurial's Convert extension. After pushing the clean repository to Kiln, all users would have to make a fresh clone. This also means that the changeset IDs would be different.

 

 

Strip the Changeset

If you only have a few changesets to clean up, another option is the hg strip extension or stripping the changesets using the Kiln web UI.

This will allow you to remove all changesets that are descendants of a specified revision (in this case, the one with the binary files).

NOTE: This will remove all work done on that repository since the binary files were committed. You will have to re-apply any changes and re-commit them. If you go this route, the recommendation is to do it on a fresh clone of the repository instead of the current working repository.

Back to top