On Thu, Feb 24, 2011 at 10:15:58AM -0700, Michael Chaffin wrote: > On Wed, Feb 23, 2011 at 2:55 PM, W. Trevor King <[email protected]> wrote: > > ... Lock successfully opened and we're moving on through > > bzrlib.dirstate.lock_write(). Your setup crashes trying to intialize > > the WriteLock. I think the reason it works for you but not for me is > > a Windows/Linux difference, since the guts of bzrlib.lock are system > > dependent (you're running _w32c_WriteLock). > > I think that is backwards, it works for you on Linux but not me on Win32 > because of bzrlib.locks. dependency on _w32c_WriteLock. Do you agree?
Your bzrlib.locks.WriteLock is actually _w32c_WriteLock, mine is
actually _fcntl_WriteLock:
>>> import bzrlib.lock
>>> bzrlib.lock.WriteLock
<class 'bzrlib.lock._fcntl_WriteLock'>
That is what I was trying to imply with my original statement. I'm
not sure which part of that you thought I had backwards...
> > Does it also successfully on your system?
>
> Here is a copy of the output from trying your attached script on my Win32
> (Windows XP Sp3) machine running ActivePython 2.6.5.14 with BzrLib 2.2.3
>
> ** SNIP **
> C:\Temp>bzr-be-test.py
> working in c:\windows\temp\tmp-bbtuqtiq1
> initialize Bazaar repo
> Created a standalone tree (format: 2a)
> create a dummy file a_file
> add the file via Python
> cleanup test directory
Note the lack of a 'success' line after 'add the file via Python'.
This is because the test script crashes the same way you had been
crashing BE. The 'cleanup' line comes before the traceback because
the `finally` clause sneaks in before the error bubbles out.
> I was going to try the new 'python -m trace --trace' trick ... on the output
> of 'bzr-be'test.py' ... but the file is 20Mb.
I certainly didn't read the whole thing either ;). If you look at my
original post, I used `grep` to pull out lines that your traceback
and the bzrlib source suggested were interesting.
> I will re-read your email and try to help out from my end.
I think your test-script crash proves that either this is a bzrlib bug
(likely) or I'm calling the cmd_add instance improperly (possible).
We've removed any BE-ness from your crash, and can consider it a
Bazaar problem.
Looking through the Bazaar list, I found a message pointing out issues
with fast lock creation/removal [1]. The associated bug has been
closed due to inability to reproduce [2], but it seems that the
Windows-specificity was never layed out as clearly in the bug comments
as it was in the original email. I also turned up another thread
discussing a bzr lock overhaul [3], but that thread is too long for me
to have read the whole thing.
I think that constitues enough research to move this thread over to
the Bazaar mailing list...
[1]:
http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/31718/
[2]: https://bugs.launchpad.net/bzr/+bug/140869
[3]: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/59166
--
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
pgpfmQQiyZBmM.pgp
Description: PGP signature
_______________________________________________ Be-devel mailing list [email protected] http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
