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 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)
- pull:
- (mostly for phase)
- and any other data the server send as a reply to the multipart-bundle The server would be able to reply a multi-bundle. To inform the client of potential phase//bookmark//changeset rewrites etc…
- (mostly for phase)
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.