|
Size: 1444
Comment:
|
Size: 2643
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 11: | Line 11: |
| * 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? |
* 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? |
| Line 27: | Line 27: |
| === New header === | === Changes in Push Orchestraction === ==== Current situation ==== * push: * changesets: * discovery * validation * actual push * phase: * discovery * pull * push * obsolescence * discovery * push * bookmark * discovery * push ==== 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 * 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… === Changesets exchange === ==== New header ==== |
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.