This page is primarily intended for developers of Mercurial.
Main proponents: Pierre-YvesDavid
This is a speculative project and does not represent any firm decisions on future behavior.
The idea is to build a new discovery protocol (both in strategy and in wire protocol). Something able to handle more than just changeset discovery but to cope with the various new data type we have introduced in the recent years.
We currently have various different data that need discovery and data exchange.
- obsolescence markers,
- Named Branches,
They are all exchanged through there own channel opening the way to multiple data complication and race condition. We would like to have a unified way to do discovery and add new kind of data to it. Eventually we would be able to gather all discovery data through the same process.
There is no real proposal yet, but lets gather some of the stuff we *need*.
- **Changeset:** find common/missing for the subset we care about,
- **Phases:** know the remote phases for the whole common set,
- **bookmarks:** know remote bookmark location for all bookmarks involved in the push one way or another,
- **obsolescences markers:** We need find missing markers for the subset we care about,
- **named Branches:** we need to know about named branch heads,
(there is probably a couple of the above that are unclear or false)
3. Pre-existing protocol
- **Changeset:** exchange list of nodes and get list of boolean "Known or not"
- **Phases:** exchange roots of all phases,
- **bookmarks:** exchange full bookmark list and location,
- **obsolescences markers:** Current algorithm then a list of nod and get a list of hash. planned algorithm send range of changesets and received list of hashes,
- **named Branches:** *I'm not sure*.
4. some random idea
We could exchange more data per round-trip and client could define how much data he want to received from the remote.
There is various data that could be combined:
- Known/missing + phases,
- branch heads + bookmarks?
- combination of the above
- phases + obsolescence markers "range"
The current discovery prototol "per node" could maybe be upgrade to "per range" to accommodate obsmarker exchange plans and probably other data type.
*Nothing to see here yet*