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

Aaron Bentley aaron.bentley at utoronto.ca
Fri Feb 2 03:00:03 GMT 2007


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

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

In order for
BzrDir.open_from_transport(branch.bzrdir.root_transport.clone('nested'))
to behave properly, clients will want consistent behavior from transports.

This sort of pattern will make a lot of sense with nested trees.

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

Will that permit listing branches in contained in subdirectories, and
all the permutations that a dumb transport could support?

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

Yes, but it's better to have an implementation that works everywhere.
Also, it would allow old smart servers to support new-format branches
which they don't natively understand.

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

If it's a BzrMeta1, it's implemented in terms of low-level ops.  I think
it would be sensible to use a different BzrDir class (SmartBzrMeta1 or
whatever) for BzrDirs managed by the smart server.

>> 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 don't understand.  You still have to have a publicly-accessible URL
for each branch.  Intercepting
http://host/user/branches/BRANCHNAME/.bzr/smart just gives you one branch.

If everything under branches is actually a branch, then you can just
intercept http://host/user/branches -- attempts to retrieve child URLs
like 'http://host/user/branches/bzr/.bzr/smart' will all be handled by
the smart server.

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

iD8DBQFFwqkz0F+nu1YWqI0RAihjAJ9yP+LOvsFIqxgXE5XfTnH9STZeNwCffNGS
9Kd09xihzMolrfLQ6a4lU0w=
=4Qpt
-----END PGP SIGNATURE-----



More information about the bazaar mailing list