-
Bug
-
Resolution: Unresolved
-
Highest
-
None
-
3.1.0-beta-2973
-
I use SourceTree with remote Windows network shares that come and go with regular use. Every time nearly any interaction is done on the UI, SourceTree decides to go lookup some data from the network shares. This, in my use case, always has a 30-90 second timeout that prevents any UI updates. Windows even thinks the program has crashed usually and I must select "Wait for application to finish". Once accessing the file actually times out, the UI usually becomes responsive again for a little bit until it decides to go and check missing network shares again.
This makes me think the thread that does the UI drawing also does the filesystem interaction which means if the filesystem is slow, the UI is slow.
I believe is is the inaccessible network shares that are causing this issue because I can see large pauses in Sourcetree's activity in Sysinternals' Procmon. I have felt the "slowness" that many many other users have reported before I started using network shares. This is different. The UI unresponsiveness for 30+ seconds only started after using network shares.
I use SourceTree with remote Windows network shares that come and go with regular use. Every time nearly any interaction is done on the UI, SourceTree decides to go lookup some data from the network shares. This, in my use case, always has a 30-90 second timeout that prevents any UI updates. Windows even thinks the program has crashed usually and I must select "Wait for application to finish". Once accessing the file actually times out, the UI usually becomes responsive again for a little bit until it decides to go and check missing network shares again. This makes me think the thread that does the UI drawing also does the filesystem interaction which means if the filesystem is slow, the UI is slow. I believe is is the inaccessible network shares that are causing this issue because I can see large pauses in Sourcetree's activity in Sysinternals' Procmon. I have felt the "slowness" that many many other users have reported before I started using network shares. This is different. The UI unresponsiveness for 30+ seconds only started after using network shares.
-
Severity 1 - Critical
I use SourceTree with remote Windows network shares that come and go with regular use. Every time nearly any interaction is done on the UI, SourceTree decides to go lookup some data from the network shares. This, in my use case, always has a 30-90 second timeout that prevents any UI updates. Windows even thinks the program has crashed usually and I must select "Wait for application to finish". Once accessing the file actually times out, the UI usually becomes responsive again for a little bit until it decides to go and check missing network shares again.
This makes me think the thread that does the UI drawing also does the filesystem interaction which means if the filesystem is slow, the UI is slow.
I believe is is the inaccessible network shares that are causing this issue because I can see large pauses in Sourcetree's activity in Sysinternals' Procmon. I have felt the "slowness" that many many other users have reported before I started using network shares. This is different. The UI unresponsiveness for 30+ seconds only started after using network shares.
