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

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.

1 answer

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:

Hope that helps

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.

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 :)

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.

Suggest an answer

Log in or Sign up to answer
Community showcase

Scrum Roles Explained: the Do's and the Don'ts

Hello Community,  Today we are going to talk about the three Scrum Roles. There is the Development Team, the Scrum Master and the Product Owner. In my opinion these three are all really impo...

112 views 1 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you