[PATCH 0 of 1] RFC: SSH transport protocol upgrade

Matt Mackall mpm at selenic.com
Wed Mar 17 17:14:01 CDT 2010


On Sat, 2010-03-13 at 16:06 +0100, Sune Foldager wrote:
> Greetings hg hackers :)
> 
> As has been discussed on the list before, I have some protocol patches
> in my queue which I would like to discuss and push. I'll recap the
> purpose and motivation for these patches below, and would like to
> start out by focusing on the SSH protocol changes, which are smaller
> than the HTTP ones.
> 
> In the following I am only talking about the transport layer of the
> protocol, i.e. how commands and arguments are encoded and handled, and
> how data is streamed. The command set, and the features of each
> command belong to another layer which I will not discuss. The
> descripion below is brief, since there has been discussions about this
> on the list earlier.
> 
> 
> PROBLEM (recap)
> 
> SSH lacks the "variable argument count" feature that HTTP has. This
> makes it hard (impossible) to extend existing commands with optional
> features. The patch in this series adds that by introducing "transport
> protocol version 2". Also, transport-layer command options are
> introduced (but not currently used; their purpose here is to unify the
> feature set with HTTP).

I think the answer here is actually "don't change existing commands".

For instance, we'd like to add some new options to the changegroup
command for lwcopies, parentdelta, etc. But we should instead just add a
changegroup2 command for this, which can trivially have a different
syntax. As it happens, we already want to change some fundamental
semantics about changegroup's arguments (whether the node list is
outside or inside the set) so this is actually a good thing.

Similarly, we don't need "client capabilities". A client queries the
server's capabilities to discover what commands it supports, then all
the logic to decide which commands/options to use on the server is in
the client, rather than split between client and server.

So generally, the model is:

- add new capabilities
- add new commands

If we have commands that already have flexible options (ie
changegroup2), then we can also add new options.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list