Comment 64 for bug 680529

I have to correct my previous post. When I said that I have to include a line
time.sleep(3), I actually lied. What I did was adding a line with
time.sleep(5). This difference seems crucial, and I need this timeout even
when I have a fast connection to the shared drive. Some further experimenting
showed that time.sleep(4.96) works fine, while time.sleep(4.95) leads to an
error.

I suspect that there is some other mechanism at work in the shadows which does
something and then deliberately waits for exactly 5.0 seconds. The fact that
I have to wait only 4.96 seconds is probably due to Python taking 0.04 seconds
on my machine to reach this point in code after triggering said mechanism.

Another experiment I made: since the commit calls wipe two times, I added a
global counter and invoked time.sleep(5) only the first time wipe is called.
This leads to the same error message as soon as wipe is called the second time.

I searched within bzrlib for the string pattern "(5", but without success
(this snippet appears several times, but always in unsuspicious ways). But
that’s not too surprising if those 5 seconds are something Windows Server 2008
specifically introduces, not bzr or qbzr.

I guess an ugly, symptoms-only fix would be something like this:

    def wipe(self):
        """Delete saved data from branch/tree config."""
        br = self._get_branch()
        if(branch_is_located_on_win_server_2008(br)):
            times.sleep(5)
        br.lock_write()
        ...