Wireprotocol changes for parentdelta

[Matt Mackall]

On Thu, 2010-07-29 at 11:50 +0200, Benoit Boissinot GSoC wrote:
> On Thu, Jul 29, 2010 at 05:01:46AM +0530, Pradeepkumar Gayam wrote:
> > Hi,
> > 
> > I am almost done with the revlog and other stuff, and started working on
> > wireprotocol. I sent some patches to the list. That was my basic idea to
> > implement. But I was told  I am heading in wrong direction. *
> > 
> > Implementaion:
> > 
> > *1)* *Query the server if it is capable of sending parentdelta'ed
> > changegroup.
> > 2) Figure out which is most efficient method to add changegroup.
> > 3) Request the chagegroup.
> > 
> > To carry out this process what I previously did was find capabilities of
> > remote server, if the server is new then request a changegroup with parent
> > deltas. It was done like this: (before unification)
> > 
> > 
> >         if pdelta:
> >             return self.do_cmd("changegroup", roots=n,
> > parentdelta='parentdelta')
> >         else:
> >             return self.do_cmd("changegroup", roots=n)
> > 
> > 
> > and server responds as below:
> > 
> >         pdelta = 'parentdelta' in req.form
> >         return  repo.changegroup(nodes, 'serve', pdelta)
> > 
> > 
> > I had to send a weird "parentdelta='parentdelta'" cause I just want to make
> > the server aware that I want parentdelta'd changegroup. In the end it turns
> > out to be the wrong way to implement.
> 
> It would completely break backward compatibility, so yes.
> > 
> > After little bit of thinking I realized adding a new command is more safe
> > and gives better functionality.
> > 
> > So now it looks like:
> > 
> > 1) Query server's capabilities
> > 2) If capable of parentdelta:
> >       Send the command "parentdelta" notifying type of repo client
> > has(Old/New) and server replies with type of repo
> >     else:
> >       Do nothing.
> 
> Why would the client need to know the server delta type ?

> > 3) Ask server for appropriate changegroup.
> 
> How do you notify changegroup() about the delta type *without* breaking
> backward compatibility? (hint you can, that why we need to introduce a
> new command *replacing* changegroup())

Also, the server is stateless. That means it has no memory of previous
commands the client has sent, so an earlier command can't affect a later
command's behavior. And no, this can't be changed: hgweb.cgi for
instance -runs a completely new instance of Mercurial for each command-.

Thus, all the protocol state and smarts must live entirely on the client
side. The server tells the client what it supports via capabilities, and
the client tells the server precisely what to send by what command it
sends.

So we're going to need a completely new changegroup command. One that
takes some option flags. The unified protocol supports varargs commands,
so handling multiple new flags should be easy.

Also, what's going on with the bundle format for parentdelta? It
currently only supports linear deltas. So we need to extend it,
otherwise the big manifests we were trying to shrink will bloat back up
10x over the wire when we do a clone or pull, which makes the whole
feature a little pointless. And that means we're going to need a new
bundle version number.

-- 
Mathematics is the supreme nostalgia of our time.