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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This message seems to have been lost.  Re-posting.

Andrew Bennetts wrote:
> Aaron Bentley wrote:
> 
>>This doesn't look like the right kind of fix.  I'm not sure what the 
>>problem with posting to sub-urls is supposed to be, but the current 
>>behavior looks right to me.  It means that you can split the load up 
>>between several servers according to URL, perhaps even with different 
>>authentication regimes.
> 
> 
> I think we want all smart protocol messages to go to the URL specified by the
> user.

I disagree here, because I think you're saying "low-level and
high-level" when you say "all".  I don't think low-level operations
should operate that way.

High-level operations should go to the URL resolved from the URL
supplied by the user, but in the case of open_containing and
find_repository, it would not make sense for high-level operations

> We're removing VFS-level operations in the smart protocol

I'm not certain that this is the right approach, because it would seem
to disable the "scan a directory root for branches" approach used by
Bzrtools' "branch" command and the Trac plugin, not to mention the
long-contemplated "garbage-collect" command.

>, in favour of
> higher-level operations like "get revisions from ABC to XYZ" and "create
> branch".  When you're talking in terms of the domain objects of BzrDirs,
> Branches, Repositories, Revisions and so on, it doesn't make sense to assume a
> particular file layout for a BzrDir.

I agree about domain objects, but when you're working with a
BzrDirMeta1, it is entirely appropriate to assume a particular
filesystem layout.

I've been assuming that smart operations will use a SmartBzrDir or
similar.  Is that correct?

> So I don't see a problem with making this transition sooner

I do.  With transports, it is assumed that
get_transport('http://a.com').clone('b') is equivalent to
get_transport('http://a.com/b').  This change breaks that assumption,
for no significan benefit.

> — it makes it
> simpler for HTTP server admins to configure a bzr smart server, and will be more
> consistent with the planned behaviour in future.

The current behavior is pretty common.  Anyone who can set up Moin ought
to be able to set up the smart server, right?

> If you want to split up load, and vary access control, by URL then you can still
> do that — you just need to arrange for different URLs for different branches

That is fine, but it is completely legitimate to do

branch.bzrdir.transport.clone('../parent-branch')

and binding to the initial URL would break that.  It would be very
natural to do this for BranchReferences, and during http redirects.

>, or
> repositories, or whatever units you want to vary the configuration for.  Each
> branch will have its own URL, and thus the HTTP server can have different rules
> for them without understanding the smart protocol

Not if we get stuck in the smart server's control and are never able to
access other branches on the same web server.

Aaron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFnVAP0F+nu1YWqI0RAhCaAKCAu3PMMf1+KP/oq6LAqHWwFyQzAACfZYCZ
IIBk2BvDrF+RzPOs8yuqjQw=
=yXee
-----END PGP SIGNATURE-----