What to do about HPSS protocol backwards compatibility for faster push?

Robert Collins robertc at robertcollins.net
Wed Oct 17 08:54:56 BST 2007


On Wed, 2007-10-17 at 16:13 +1000, Andrew Bennetts wrote:
> As the smart server protocol changes, we need to make sure that different
> versions of the client and server can interoperate.  In many cases this easy: if
> new versions of the server supports older request methods, then older clients
> will continue to work.  Similarly, new versions of the client can often support
> older servers at minimal cost, by simply trying a request, and if the server
> doesn't recognise it, downgrade to something else.  The cost is one wasted
> roundtrip, a bit of fairly simple fallback logic in the client, and keeping the
> old request logic in the client and server.
> 
> If the request is large (e.g. pushing 10MB container of revision data), then
> this isn't so good.  Sending a 10MB request just to get back a “sorry, I don't
> understand” response is going to be pretty slow.  What should we do about this?

IMO, Nothing. Log the fact this happened clearly, and advise them to
upgrade the server. That is, your option '2' below.


> Does anyone have any comments, or other suggestions?

I think 4) is useful for some people, but actually likely to cause harm.
(imagine a client with the config set well after the server was
upgraded).

Our general policy is that latest bzr <-> old bzr will work, but may be
slower. 

This situation doesn't seem any different to me than pushing from a pack
to a knit repository a 10MB project, which will be excruciatingly slow.

-Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20071017/222da622/attachment.pgp 


More information about the bazaar mailing list