[RFC] Add a Transport.human_url method?

Andrew Bennetts andrew.bennetts at canonical.com
Fri Jul 24 05:39:46 BST 2009

This idea sprang from my patch about LockContention errors that I'm about to

Currently there are two ways to get a URL from a Transport: t.base and
t.external_url().  I don't think these two methods quite cover all our use

1. base: is for in-process use.  You can do get_transport(t.base) and get a
    transport object equivalent t.  t.base might not be meaningful outside of
    this process (e.g. for memory or chroot transports, or decorated

2. external_url(): is for sharing with other processes.  Another process on this
    host can probably use this URL to access the same resource (modulo
    authentication etc).  If there is no such URL then it raises an exception.

I think there may be value in having a third method:

3. human_url(): is for reporting to humans in errors and the like.  This is
    t.external_url() if it exists, but otherwise t.base, which is still better
    than nothing.  The attached patch to implement this basically moves a
    private helper that my LockContention patch added to a public method of

Thinking about this, perhaps the LockContention serialisation in my patch is
still not quite ideal... ideally we'd be sending relpaths over the wire rather
than URLs.  Hmm.  Although I can imagine cases where the server might legitimately
want to send an error about a LockContention on a lock not on that host, but
perhaps that's too marginal.

What do other people think?


[1] https://code.edge.launchpad.net/~spiv/bzr/lockcontention-bugs/+merge/9228
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc-external-url-4565.patch
Type: text/x-diff
Size: 4287 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090724/8dba7aef/attachment.bin 

More information about the bazaar mailing list