Wouter van Heyst wrote:
> On Sun, May 03, 2009 at 02:16:26AM -0000, Andrew Bennetts wrote:
[...]
> > a) make the client ignore whatever URL the server returns when generating the break-lock message, or
[...]
>
> I tried to do a), but I fail to see how to do that. At the point where
> the message gets dumped to screen, it happens magically to me, without a
> point where I can intervene.
>
> I can not find the point in the code to apply a)
In bzrlib/remote.py, RemoteBranch._remote_lock_write makes the RPC call, and
the global _translate_error function in that module converts error responses
from the wire into regular bzrlib exceptions, e.g. LockFailed and
LockContention. It's the LockContention translation that produces this part
of the output: “Could not acquire lock "(remote lock)"”
The message in the bug report seems to be printed by the wait_lock method in
bzrlib/lockdir.py though. I'm not sure how that's getting invoked here,
maybe stick a "import pdb; pdb.set_trace()" or "import traceback;
traceback.print_stack()" or similar in there just before it calls
self._report_function? Oh, _report_function is bzrlib.trace.note: that text
is actually being emitted *server-side*, and SSH is faithfully conveying it
to the local terminal. If you run a local TCP bzr server (with “bzr serve
--allow-writes”) you'll see that the server process does the printing!
So actually a) has a few parts:
a.1) make the client ignore the URL from the server (except perhaps if it is
a relpath).
a.2) fix bzrlib.lockdir to not spew over stdout. It's mixed UI code with
low-level logic.
a.3) make the text that bzrlib.lockdir get spewed in a more appropriate
place so that the client can do it (and substitute in its own URLs).
Wouter van Heyst wrote:
> On Sun, May 03, 2009 at 02:16:26AM -0000, Andrew Bennetts wrote:
[...]
> > a) make the client ignore whatever URL the server returns when generating the break-lock message, or
[...]
>
> I tried to do a), but I fail to see how to do that. At the point where
> the message gets dumped to screen, it happens magically to me, without a
> point where I can intervene.
>
> I can not find the point in the code to apply a)
In bzrlib/remote.py, RemoteBranch. _remote_ lock_write makes the RPC call, and
the global _translate_error function in that module converts error responses
from the wire into regular bzrlib exceptions, e.g. LockFailed and
LockContention. It's the LockContention translation that produces this part
of the output: “Could not acquire lock "(remote lock)"”
The message in the bug report seems to be printed by the wait_lock method in print_stack( )" or similar in there just before it calls function? Oh, _report_function is bzrlib.trace.note: that text
bzrlib/lockdir.py though. I'm not sure how that's getting invoked here,
maybe stick a "import pdb; pdb.set_trace()" or "import traceback;
traceback.
self._report_
is actually being emitted *server-side*, and SSH is faithfully conveying it
to the local terminal. If you run a local TCP bzr server (with “bzr serve
--allow-writes”) you'll see that the server process does the printing!
So actually a) has a few parts:
a.1) make the client ignore the URL from the server (except perhaps if it is
a relpath).
a.2) fix bzrlib.lockdir to not spew over stdout. It's mixed UI code with
low-level logic.
a.3) make the text that bzrlib.lockdir get spewed in a more appropriate
place so that the client can do it (and substitute in its own URLs).
Brief reproduction notes:
$ cd /tmp open('/ tmp/locked- branch' ).open_ branch( ).lock_ write() "
$ bzr init locked-branch
$ python -c "from bzrlib.bzrdir import BzrDir; BzrDir.
$ bzr --no-plugins serve --allow-writes
[now launch a separate terminal]
$ bzr push -d [path-of- any-branch] bzr://localhost /locked- branch
-Andrew.