Code review comment for lp:~spiv/bzr/lockcontention-bugs

This looks ok, though I do wonder if having a class that sometimes contains a real lock object and sometimes a repr will cause problems for code that catches this exception.

If we're only ever going to print it, why not just always use a string?

If we're going to use the object, passing a string may cause failures.

It may be that code never uses the object, but humans sometimes poke at it from debuggers and they can be relied upon to know the difference.

If we did require it to be an object, I suppose we could create some kind of stub for a remote lock that fulfils the protocol but refuses to do anything, but for now that'd be excessive.

A similar issue occurs for any error that holds an object...