windows selftest rev 1372

[Alexey Shamrin]

On 29/10/05, John A Meinel <john at arbash-meinel.com> wrote:
> Alexey Shamrin wrote:
> > Sorry, I wanted to say that the tests were hanging before, not now.
> They aren't hanging for you? Interesting, because they are for me.
> Basically what is failing is this code in blackbox.py:
> [...skipped...]
> In my understanding, under windows when a single process asks for a
> second lock, it will actually block, waiting for the earlier lock to be
> released.
>
> Now, in our Win32 changes from Alexander, any lock that actually blocks
> will raise an exception, rather than hanging.
> Under cygwin (where I am testing for right now), it does not perform
> this trickery, and does block.
>
> It seems that on Linux, asking for a shared lock, when you already have
> an exclusive one, is a no-op. But this is not true on Windows.
>
> I think we need to go back to what Aaron Bentley recommended, and turn
> our locks into singletons. We can then decide if we would rather "bzr
> pull ." succeeds or throws a multi-lock exception.
>

I can only confirm that bzr selftest does hang under cygwin (and
doesn't under plain win32). Here are last several lines of output of
bzr selftest --verbose (rev 1372):

Merge handles missing file conflicts                                  OK (Took 2
.040s)
Test two modes of operation for mv                                    OK (Took 0
.524s)
bzrlib.selftest.blackbox.TestCommands.test_other_branch_commit        OK (Took 0
.719s)
Pull changes from one branch to another.

I cannot say add anything about the details because I haven't tried to
dig into this problem.

--
Alexey