[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