[MERGE] bzr+http:// should always try POSTing to the same location, not lots of child locations.

[Andrew Bennetts]

John Arbash Meinel wrote:
> Andrew Bennetts wrote:
> > There's a problem with the current bzr+http:// transport.  If you do e.g.  "bzr
> > branch bzr+http://host/foo", it ought to just POST lots of requests to
> > http://host/foo/.bzr/smart, but it ends up POSTing to many different URLs below
> > that point, e.g. http://host/foo/.bzr/branch/.bzr/smart.  That is, instead of
> > sending "get\x01.bzr/branch/format" to $URL/.bzr/smart, it will send
> > "get\x01format" to $URL/.bzr/branch/.bzr/smart.
> > 
> > This is preventing bzr.dev from working with bzr+http://bazaar.launchpad.net/*
> > URLs at the moment.
> > 
> > This bundle fixes that, by making cloning of SmartHTTPTransport remember the
> > inital URL, so that it can always POST to the intended location.  
[...]
> 
> What about repositories that are outside the branch. Specifically:
> 
> http://bzr.arbash-meinel.com/branches/bzr
>                                          /jam-integration
> 
> bzr/.bzr/repository
>    jam-integration/.bzr/branch
> 
> I realize we don't want to be sending to:
>   jam-integration/.bzr/branch/.bzr/smart
> 
> But we don't want to be sending:
>  ../.bzr/repository/knits/...
> 
> to jam-integration/.bzr/branch either.
> 
> So maybe have something different for clone('..')
> 
> So I'm -0 with your current fix. I think it fixes the Launchpad case,
> but it really breaks other cases. I *really* don't want to send any
> paths with '..' in them.

This is an interesting case.  Thinking out-loud about what this will look like
in the future, when the smart protocol is doing high-level operations rather
than file-level operations, I can see two obvious ways the smart protocol might
go.  Obviously we won't be doing the current "see if there's a repo here, else
clone('..'), rinse and repeat" dance.

  1. There could be a smart method like "find repository" that will return the
     location (as a relpath) of the repository to use for a particular URL.

  2. There could be a smart method like "has repository" that just says if there
     is a repo there or not, and all other methods that operate on the
     repository (e.g. "get revision", "add revision", etc) let the server worry
     about the location of the repo.

In option 1, because the location may be a parent URL, we may need to open a new
transport, but that's ok because it can share the existing connection (if
applicable for the type of transport).  Or we could allow paths with "..", but I
think we're all agreed that that's undesirable.

In option 2, the server will take care of it, so the client doesn't need to know
precisely where the repository is, so there's no need for ".." paths here
either.

So I agree; this interim improvement to the VFS smart client should do something
different with clone('..'), because we don't want to send ".." paths, and our
future plans don't involve them either.  I'll update my bundle accordingly.
Thanks for listening :)

-Andrew.