[MERGE] Transport.get_directory is undefined

[John Arbash Meinel]

Aaron Bentley wrote:
> Robert Collins wrote:
>>> I've taken a stab at defining reliable behaviur for transport.get('a
>>> directory')
> 
>>> +    * ``Transport.get`` has had its interface made more clear for ease of use.
>>> +      Retrieval of a directory must now fail with either 'PathError' at open
>>> +      time, or raise 'ReadError' on a read. (Robert Collins)
> 
> I don't understand how you can guarantee that for http.  In fact, I
> don't see any changes to the http implementation.  And currently, the
> branches plugin makes use of the fact that http servers often return an
> index, so changing get to fail on directories would be a bit unhelpful.
> 
> Aaron

So, the only place I know of that ever thinks about get(directory) is
the read_bundle_from_url() which is called by 'merge' and 'pull'.
Because *if* the argument is a file *and* the file contains a Bundle
header, then it is treated as such.

Robert's original concern is that I was testing read_bundle_from_url
against all transports, because sftp had different behavior than
everything else.

He felt the better fix was to make the Transport API consistent. Though
you point out another way that makes it difficult.

I'm sure he switch LocalTransport to returning a delayed error, because
he wants to make sure there aren't any latent bugs elsewhere in the code.

The simple fact is we don't get() random things, we only get() after
things which we expect to be files (like .bzr/branch-format, etc).
*Except for* read_bundle_from_url.

I suppose we might have some weird bugs if someone had a directory named
.bzr/branch-format/ on their remote filesystem, and then we did:

bzr log sftp://remote/foo
would give different results than
bzr log /local/foo
or
bzr log http://remote/foo


I feel like Robert is overengineering things a little bit. Because he is
trying to make a feature of transports consistent, which is actually
quite inconsistent by the nature of the transports. And shouldn't be
something that we rely upon.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060929/5f2222c9/attachment.pgp