Differences between revisions 6 and 7
Revision 6 as of 2005-08-26 01:36:47
Size: 1567
Editor: waste
Comment:
Revision 7 as of 2005-09-06 20:39:48
Size: 2733
Editor: EricHopper
Comment: Tried to clarify things. Put overview ahead of low-level description not after
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
=== Overview ===
The first three functions are used to efficiently track back through a
remote tree to find the roots of all the new branches, without a
massive number of round trips or needing to send the entire changelog
list.

The fourth actually gets all the changes in one go.

=== The Protocol ===
Line 13: Line 22:
 * list = a list of tips
 * tip = the last revision in a branch that we're interested in (often a head).
 * base = the first revision going backwards from the tip that has two parents (the product of a merge).
 * p1 = the first parent of the base.
 * p2 = the second parent of the base.
Line 20: Line 34:
 * branch = Basically a linear set of changes. More formally, a list of changes such that no change in the set (except possibly the last) has two parents, and all changes in the list are related to eachother by parent->child relationships.
 * list = a list of (tip, base) tuples for branches we'd like to know the history of. Presumably the client knows about the base of the branch, but not the tip, and wants to find out where in the branch its knowledge ends.
 * tip = the latest revision in a branch the client is interested in (may not be the actual tip of the branch on the server side)
 * base = the earliest revision in a branch the client is interested in. Always a revision the client knows about.
Line 26: Line 44:
 * roots = a list of the latest nodes on every service side changeset branch that both the client and server know about.
Line 42: Line 61:
{{{
 
}}}

----
Line 47: Line 66:

The first three functions are used to efficiently track back through a
remote tree to find the roots of all the new branches, without a
massive number of round trips or needing to send the entire changelog
list.

The fourth actually gets all the changes in one go.

The Mercurial wire protocol

Mercurial performs all of its network transactions over HTTP.

Overview

The first three functions are used to efficiently track back through a remote tree to find the roots of all the new branches, without a massive number of round trips or needing to send the entire changelog list.

The fourth actually gets all the changes in one go.

The Protocol

The network protocol looks like this:

heads()

 return a list of heads
 (everything new must be an ancestor of one of these heads, so start here)

branches(list)

  • list = a list of tips
  • tip = the last revision in a branch that we're interested in (often a head).
  • base = the first revision going backwards from the tip that has two parents (the product of a merge).
  • p1 = the first parent of the base.
  • p2 = the second parent of the base.

 for node in list:
   follow the linear section of a branch back to its branchpoint
   return (tip, base, p1, p2)
   (this reduces round trips for long linear branches)

between(list)

  • branch = Basically a linear set of changes. More formally, a list of changes such that no change in the set (except possibly the last) has two parents, and all changes in the list are related to eachother by parent->child relationships.

  • list = a list of (tip, base) tuples for branches we'd like to know the history of. Presumably the client knows about the base of the branch, but not the tip, and wants to find out where in the branch its knowledge ends.
  • tip = the latest revision in a branch the client is interested in (may not be the actual tip of the branch on the server side)
  • base = the earliest revision in a branch the client is interested in. Always a revision the client knows about.

 for tip, base in list:
   walk back a linear branch, return elements 1, 2, 4, 8..
   (and this lets us do bisection search if we diverge in the middle of one of these long branches)

changegroup(roots)

  • roots = a list of the latest nodes on every service side changeset branch that both the client and server know about.

 find all changesets descended from roots and return them as a single changegroup

A changegroup is a single stream containing:

  • a changelog group
  • a manifest group
  • a list of
    • filename length
    • filename
    • file group (terminated by a zero length filename)

A group is a list of chunks:

  • chunk length
  • self hash, p1 hash, p2 hash, link hash
  • uncompressed delta to p1
  • (terminated by a zero length chunk)


Hgweb/remoterepository currently runs this all through zlib which makes sense on WANs, but less sense on LANs.

WireProtocol (last edited 2011-05-01 12:19:06 by PeterArrenbrecht)