Comment 3 for bug 439003

If you enable icons, then we have to read the remote files to check there status. (Are they up-to-date relative to the last commit.)

Reading all of the content will peg your network until we finish. Once we've done it 1 time, then likely we won't continue to do so, as long as the 'stat' of the file doesn't change. I've heard rumors that some network mounts don't preserve all the bits of stat (I think they handle mtime, but not 'ino' and 'dev', for example). If that is true, then we would continually re-read the files whenever they look like they might have changed.

So:
 1) I'm not surprised you saturate your network the moment you turn icons on (it is the same as doing 'bzr status' on the remote drive.)
 2) I would expect it to get better once it has finished the first time. (Although depending on the details of the network share, it is possible that multiple people looking at the same share will get different information, and trigger issues where each sides try to set the 'current' state to their view. There really isn't much we can do in that situation, because the network share is telling us the content has changed when it really hasn't.)

The general recommendation is that you shouldn't have working trees on network shares unless really necessary. Local lightweight checkouts of network branches & repositories generally work much better.