4887
Comment:
|
4892
|
Deletions are marked like this. | Additions are marked like this. |
Line 114: | Line 114: |
* HG10 (old changeset bundle format) * HG19 (new changeset bundle with support for modern stuff) * pushkey data (phase, bookmarks) * obsolescence markers (format 1 and upcoming format 2 ?) * client capacity (to be used for the reply multi part bundle) |
* HG10 (old changeset bundle format) * HG19 (new changeset bundle with support for modern stuff) * pushkey data (phase, bookmarks) * obsolescence markers (format 1 and upcoming format 2 ?) * client capacity (to be used for the reply multi part bundle) |
Note:
This page is primarily intended for developers of Mercurial.
This page describes the current plan to get a more modern and complete bundle format. (for old content of this page check BundleFormatHG19)
Contents
(current content is copy pasted from 2.9 sprint note)
New bundle format
- lightweight
- new manifest
- general delta
- bookmarks
- phase boundaries
- obsolete markers
>sha1 support
- pushkey
- extensible for new features (required and optional)
- progress information
- resumable?
- transaction commit markers?
It's possible to envision a format that sends a change, its manifest, and filenodes in each chunk rather than sending all changesets, then all manifests, etc. capabilities
Changes in current command
Push Orchestraction
Current situation
- push:
- changesets:
- discovery
- validation
- actual push
- phase:
- discovery
- pull
- push
- obsolescence
- discovery
- push
- bookmark
- discovery
- push
- changesets:
Aimed orchestration
* push:
- discovery:
- changesets
- phase
- obs
- bookmark
- post-discovery action:
- current usecase move phase for common changeset seen as public.
- local-validation:
- (much easier will everything in hands)
- complains about:
- multiple heads
- new branch
- troubles changeset
- divergent bookmark
- Rent in Manhattan
- etc…
- push:
- (using multipart-bundle when possible)
- The one and single remote side transaction happen here
- (using multipart-bundle when possible)
- (post-push) pull:
- The server send back its own multipart-bundle to the client
- (The server would be able to reply a multi-bundle. To inform the client of potential phase//bookmark//changeset rewrites etc…)
- The server send back its own multipart-bundle to the client
post-push pull
If we lets the protocol send arbitrary data to the server, we need the server to be able to send back arbitrary data too.
The idea is to use the very same top level format. It could contains any kind of thing the client have advertise to understand. This last phase is advisory this the client can totally decide to ignores its content.
Possible use case are:
- sending standard output back
- sending standard error back
- notification that a changeset was made public on push
- notification of partially accepted changeset
- notification of automatic bookmark move on the server
- test case result (or test run key)
- Automatic shipment of Pony to contributor address
- … (Possibility are endless)
Changes in Pull
Same kind of stuff wil happen but pull is much simpler. (I'm not worried at all about it)
Change in Bundle/Unbundle
Unbundle would learn to unbundle both
Maybe we can have the new bundle format start with an invalide entry to prevent old unbundle to try to import them
bundle should be able to produce new bundle. It can probably not do it by default for a long time however :-/
Top level Bundle
content
On the remote side, the server will need to redo the validation that was done on the remote side to ensure that nothing interesting happened between discovery and push. We need to send appriopricate data to the remote for validation. This implies either argument in the command data. Or a dedicated section in the bundle. The dedicated section seems the way to go as it feels more flexible. We do not know what kind of data will be monitored and send. So we cannot build a sensible set of argument doing the job. With a dedicated section in the multi-part bundle, we can make this section evolve over time to match the evolution of data we send to the server.
forseen sections
Here are the idea we already have about section
- HG10 (old changeset bundle format)
- HG19 (new changeset bundle with support for modern stuff)
- pushkey data (phase, bookmarks)
- obsolescence markers (format 1 and upcoming format 2 ?)
- client capacity (to be used for the reply multi part bundle)
Changesets exchange
New header
type Header struct { length uint32 lNode byte node [lNode]byte // if empty (lP1 ==0) then default to previous node in the stream lP1 byte p1 [lP1]byte // if empty, nullrev lP2 byte p2 [lP2]byte // if empty, self (for changelogs) lLinknode byte linknode [lLinknode]byte // if empty, p1 lDeltaParent byte deltaParent [lDeltaParent]byte }
We'll modify the existing changegroup type so it can pretend to be a new changegroup that just has a variety of empty fields. Progress information fields might be optional.