Background activity indication + single-session disable option (bandwidth management)

[Walter Stanish]

I travel a lot like I suspect many developers and often operate on low bandwidth connections.

Whilst the Check default remotes for updates every <x> minutes option is both configurable and possible to disable, it seems that I have had it running on poor connections with a high frequency (10 minutes) and have been wasting a lot of bandwidth.

It would be very useful to have some form of always-visible (but possible to disable) background process notification and and a corresponding option on the notifications to disable background operations for this session.

[KieranA]

Hi Walter,

I've spoken to a few people about this before and it is an issue, especially when developers have 40 or so repositories but they're only using one of them for a month. They don't want their other repositories to refresh, only the one they're actively using. I've filed an issue for this one here: https://jira.atlassian.com/browse/SRCTREE-1454

Hope that helps

[Walter Stanish]

Thanks Kieran. The one-per-month notion you mention is indeed close to my own workflow (though perhaps more like 3-4 per month). The enable/disable could get tedious if manually achieved. I still think an overall or session-based block on background updates would be a simple and workable solution. Often people are on low-bandwidth links for short periods (eg. at conferences, overseas, on mobile, etc.) and this saves them having to fiddle with their normal config.

[KieranA]

I think the option would be something really simple, like a checkbox next to a repo in the bookmarks list. More likely we'd have something like "24 days since last check" with a green/amber/red indicator so it's visually showing you what's going on without having to read anything. If you're happy with that you could make further comments on the JIRA issue and perhaps mark this as answered :)

[Walter Stanish]

I believe session-disable is better than a bookmark checklist in many cases because: (A) Preference may be related to bandwidth management and therefore of a temporary nature (B) Single option that affects the current session and is restored later does not affect overall configuration (for example in normal environment) (C) Single option is less clicks (saves time) for the user (D) Single option can pop up or be otherwise made available even if you are working on a repo screen (as per suggestion of displaying somehow SourceTree's background activity) .. whereas the per-repo thing would mean leaving the normal working part of the program to go back to check/uncheck individual repos (E) Repos are potentially extremely numerous. For example I have 78 in my code dir at the moment.