Repository Registry blocks workbench opening

Issue #940 resolved
Anonymous created an issue

Repository Registry seems to validate/check each repository, which can prevent HG Workbench from opening until this check is done.

In my case there was a network repository, which did not exist anymore. So it took the full network-access timeout until Workbench finally opened. (around 10-20 seconds...) which was really annoying. Removing the non-existant repository fixed the problem and workbench opened fast again.


A: Maybe run those checks in another Thread, and do not block workbench from opening?

B: Add an option to disable the repository registry creation/checking/usage at all? (Personally I do not use it anyway)

Comments (17)

  1. Anonymous

    Thx for your answer!

    Hm, this option seems to switch itself on again after disabling it. I even forced it to false in "TortoiseHgQt.ini"

    But still the network-timeout delay for unreachable repositories. Example out of "thg-reporegistry.xml":

    <repo root="\\\TestRepository" shortname="Test" basenode="03c75e572db5d652b769c285ec0bc18110d3a011"/>

    Where is a non-existent network address. (So actually no subrepository involved)

  2. Jon Mabe

    FWIW: I had long (30 to 60 second) load times for the Workbench because of this issue. I remedied it by unchecking the Subrepos options, and further remedied by disabling the kbfiles extension. The entire problem is exacerbated by the fact that I got in the habit of opening the Workbench on Subrepos themselves (don't ask me why) so my Repo Registry has something 75 items in it (I know that's ridiculous, I'm cleaning it up now).

    Finally, it took me loading up the Sysinternal's Procmon.exe to realize that Workbench was spending so much time on those unrelated Subrepos (to the one I was opening the Workbench on). I didn't even think about it because I had the Repo Registry window closed. Maybe consider not touching all that when that window isn't enabled?

    Anyway, I hope I dropped enough keywords into my comment that it helps someone else furiously searching through the issues for this same problem.


    Problem doesn't (seam to) occur in 2.0.5, I checked three versions of 2.1.x (2.1.1, 2.1.2, 2.1.3) and it occurs in all versions. I only tested/use x64 versions of the app.

  3. Anonymous

    It's minutes here! Running Win7 x64. TortoiseHG 2.1.4. I consider the workbench unusable because of this slow load!

    I went to the menu View -> Repository Registry Options

    Unchecked both Show Subrepos on Registry Show Subrepos for remote repositories.

    Why are these options on if they're such a time sync?

    Or as stated, putting that update into a background thread so you can work with the workbench right away would be good.

  4. Anonymous

    I have this problem too. It's very annoying. It takes nearly one minute to show Workbench window. I have version 2.2.2.

    Please consider testing of repository path accessibility in background thread for network paths. Just start thread, copy repository path to local buffer, try GetFileAttributes for repository path (it works pretty well in our file manager Altap Salamander), store result in thread exit code, and end thread. If thread does not end in 1 or 2 seconds, it means path is not accessible.

    Or simply show "inaccessible" icon for all network repositories and test accessibility as late as when user clicks them.

    We are using repository on server in virtual machine, it's started only when we need this repository, so I have to delete this repository from list in Repository Registry whenever I use it, or it blocks starting Workbench when this virtual machine is down.

    Despite this little problem, many thanks for this great application!

    Petr Solin

  5. Anonymous

    Would also like to disable the registry, we use feature repositories and it quickly gets out of hand the number that show up in the registry, as I never use it I don't want it querying them.

  6. Eduard-Cristian Stefan

    I have observed two patterns:

    1. inside repos I'm opening the workbench as often as required by the activities on that project and sometimes open some other repos from the same group
    2. I'm opening the workbench from the contextual menu (outside any repo) just to check multiple unrelated projects for updates

    Is it possible to add an option so that if I open the workbench from inside a repo it will not check any repository registry paths until it is explicitly accessed by the user?

  7. Angel Ezquerra

    The loading of the Repository Registry happens when the Workbench is created (i.e. at startup time).

    The most recent version of TortoiseHg has a new setting in the Workbench settings panel called "Single workbench window". I recommend you that you enable it.

    When this option is enabled, TortoiseHg will try to reuse an existing workbench window when you use the TortoiseHg explorer (or nautilus/finder) context menu item "Hg Workbench".

    This means that if you are careful to not close the workbench window once it is open, opening new repositories through the context menu will be very fast since you will not incur the cost of populating the repository registry.

    This is not exactly a solution to the problem you guys have but is something that can help a lot. Of course the solution is to populate the repository registry in a background thread. This is something that is being looked into.

    As an additional advice, I would suggest not opening remote repositories through the workbench. Working on repositories that are located on network drives is unreliable at best, particularly on windows.

  8. pmv

    I agree populating the registry in a background thread is the proper fix. However, if that will take a while to accomplish, maybe an option to only add certain paths to the registry would accomplish the same thing and may be easier?

    For example, on windows I put all repositories under C:\hg If I could specify that as my repository location, only add things to the registry if they're in a sub-directory of that. If I open something from a share drive (S:\hg), it wouldn't be added to the repository registry.

    Just a thought. Thanks for this great application!

  9. Yuya Nishihara

    reporegistry: rename "Show Subrepos" option to "Scan Repositories" (closes #940)

    Now subrepos are populated when opening new repository, and stored in thg-reporegistry.xml, this option is only effective at startup. Because scanning filesystem is slow, it's off by default.

    → <<cset 5374fa471362>>

  10. Log in to comment