Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

SourceTree is super slow in Multi-level Hg

Kittichai Jirasukhanon July 15, 2012

My repository is 2-level. I have sub-repo and main repo (which only update .hgsubstate). There are 8 subrepos currently. Here's how it is very frustrating:

1) When I click on "Commit View" on main repository (The check button), it takes 10-20 seconds before it can list sub-repos that has been changed.

2) Let's say there are 3 sub-repos changed, when clicking "Commit" which bring up commit dialog, it give me a progress bar again which I don't know what the hell it check sub-repos for when it just check. This takes another 10-15 seconds before sub-repos display what should be commit correctly.

3) When I commit all subr-repos and close dialog so I can get back to main repos, it check again! That takes another 10-15 seconds yet again. So, for total, if I have 3 different changes sub-repos, it takes 2 minutes for me to commit (excluding time to type comments). If I'm unlucky, some other developer will already commit something else which will force me to merge-commit again. So, there's now another policy in my office, I would yell to everyone whenever I open SourceTree so they will know not to do anything until I'm done. So much for distributed source control.

By the way, all these repos are on SSD Intel 520 series. I'm using Mac OS X Lion 10.7.4 and SourceTree 1.4.4.

And this issue happens for all Mac machine in my office, which are Lion and Snow Leopard.

Compare to TortoiseHg for Windows, commit process takes less than a second.

I plan to go back to Windows because there's no good Hg client on Mac. Other likes MacHg doesn't support 2-level repos. And SourceTree is super slow and not refresh sub-repo correctly.

PS. I just download MacHg and uses it on existing repository, it can check the update almost instantly. So, I don't think it's anything to do with my repos.

2 answers

0 votes
Kittichai Jirasukhanon July 16, 2012

1) I can't allow you to access my repository, obviously. I can only tell you that there are 8 sub repos, total files are around 3,500. And there are ranging from 2,000 - 7,000 revisions, and total size is around 1.8 GB. And main repos server uses SSH, which should be irrelevant to this problem since it slow at checking what to commit as well. Pull and push are also slow.

2) I have keep in mind that the system that doesn't check subrepos will be much faster. But SourceTree repeatedly check sub-repos too often than necessary. If it only slow at commit time, then I may able to live with it. But it slow at every step as I have described above. And SourceTree is slow even if I just try to commit things in sub-repos, not at main repos. (that should be treated as one-level repos)

When I install MacHg and point to the same sub-repos (I don't know how MacHg works with multi-level repos, so I didn't compare it). MacHg can Check Commit on the same sub-repos almost instantly, while SourceTree takes 5-10 seconds.

Never mind, I have found solution. I have installed TortoiseHg on Windows 7 on Parallel and map Mac directory to it. It's obviously faster, you can see what change instantly, not in seconds. You should try TortoiseHg on the same repos as SourceTree and see its speed. I'm happy. It save me 2 minutes for every commit, at least.

3) By the way, TortoiseHg also check subrepos, and it takes just a second to show me all sub-repos that has been changed. Fast, and commit time is unnoticeable, the way source control should be. You should try it on your repos and compare the speed.

My point is, you should compare your product with competitors. I still love your UI compare to MacHg. Hope your will get better some day.

0 votes
stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 16, 2012

Is there a test repo we can use to reproduce this behaviour? I have quite a few repos with multiple subrepos and I don't see anywhere near this level of delay (and I don't have an SSD).

Bear in mind that systems that don't check subrepos will obviously be a bit faster to refresh the status because it's ignoring the subrepos.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events