[RFC] Server-side branching

Andrew Bennetts andrew at canonical.com
Tue Jun 5 08:35:27 BST 2007

Martin Pool wrote:
> On 6/5/07, Andrew Bennetts <andrew at canonical.com> wrote:
> >Thoughts?
> As we add new commands that do more than the transport layer we should
> make sure they're documented somewhere.  The Request class is probably
> a good place, so rather than just
> +    """Server-side repository content fetching."""
> we should probably make a practice of saying what the parameters are,
> what specifically it does, and in what bzr version it was introduced
> and (where applicable) deprecated.

I think this is a very good policy.  I'll adopt it.

> The name 'fetch_to' seems strange - it's invoked as
> target.fetch_to(source) iiuc, so it really acts like 'fetch_from'.

Yeah, it is a poor name.

> Maybe we should really be passing the whole 'branch' operation across
> rather than just the 'fetch'?  Maybe this fetch is an easier step for
> now.

Passing the whole branch operation would avoid a bunch of opening the bzrdir and
other stuff that causes roundtrips, so I think it would be a good idea.
Possibly a good enough one to justify starting over.  I mainly wanted to get
something going as quickly as possible, to see roughly what would be involved.

> +            # XXX: what about <= 0.16 servers that don't have this method?
> +            raise errors.UnexpectedSmartServerResponse(response)
> Don't we have support now to say that this was specifically 'command
> not understood', rather than a more general error?  If not, we should
> add it, and the caller (sprout) can then catch that and fall back to
> the old method.

Right.  This comment is basically there as a reminder that fallback support
for this operation needs to be added.

> Your patch assumes that if the hostname is the same, we can ask the
> server to do the branching.  That's probably reasonable in general,
> but as Robert notes sometimes it won't work, and the server needs a
> way to decline.

The best solution I think is Vincent's "Tracking multiple connections" work,
which should allow us to do this properly.


More information about the bazaar mailing list