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

[Andrew Bennetts]

Aaron Bentley wrote:
> Andrew Bennetts wrote:
[...]
> > 
> > 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

Perhaps, although I think most, if not all of the time, the client doesn't want
to know where the remote repository (or branch) is exactly, it just wants to be
able to do things with it.  And I think it will be useful for servers to be able
to cleanly implement non-standard repository locations (I think this may be
useful for bazaar.launchpad.net for instance, although I haven't thought hard
about the details yet).

> > 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.

I imagine these could, and probably should, both be implemented as higher-level
requests: "list-branches" and "garbage-collect".  The latter in particular
really seems like the sort of operation that would be much faster with a smart
server than a client doing VFS operations.

> >, 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.

The client (mostly) doesn't care what format the branch on the server is, just
that it can do operations to it.

(I say "mostly", because older formats tend to support less features, e.g. might
not support tags, but even that can handled without the client needing to find
out in advance what the format is; just return an error and let the client
report it and suggest they run the upgrade command).

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

Yep, that's the plan.

> > 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.

For the significant benefit that it makes the existing HTTP smart server much
easier to deploy (and more consistent with smart servers that run over
byte-stream media).  Configuring e.g. Apache to intercept
"http://host/user/branches/BRANCHNAME/.bzr/smart" is easier than configuring it
to intercept "http://host/user/branches/*/.bzr/smart", where "*" can be
arbitrary number of directories deep.  I'm sure it can be done, but for someone
like me that knows relatively little about Apache configuration (and would like
to keep it that way!), I'd rather things were simpler.

> > — 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?

See above.  I can say from personal experience it's easier to set up Apache this
way.  I'm sure that's at least in part due to my lack Apache knowledge, but I
think this is a valid concern.

> > 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.

My current patch breaks the stickiness as soon as you clone above the initial
URL, after you and John pointed this out.

> >, 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.

I think this is solved by the current patch (which breaks stickiness when
cloning upwards).

-Andrew.