[PATCH 1 of 5 V2] bundle2: very first version of a bundle2 bundler

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Mar 20 18:01:31 CDT 2014



On 03/20/2014 03:08 PM, Matt Mackall wrote:
> On Thu, 2014-03-20 at 11:39 -0700, pierre-yves.david at ens-lyon.org wrote:
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at fb.com>
>> # Date 1395176450 25200
>> #      Tue Mar 18 14:00:50 2014 -0700
>> # Node ID 14623bafac62835e44ee4dee806978e1fd50540b
>> # Parent  29b159bd71bc68e9868c5d2d748ab166dc7a5287
>> bundle2: very first version of a bundle2 bundler
>
> The big question I have from looking at this is how does it fit into the
> existing framework? There is basically no similarity between these
> classes and the existing bundle10/unbundle10 classes (which really
> strongly suggest a naming scheme you ought to be using for your new
> classes, no?) that I would expect them to eventually be
> duck-type-compatible with.

(Naming hint taken)

They are few similarity between the two, because they differ a lot in 
they usage, bundle10 focus on exchanging changesets, where bundle20 will 
be used by much more different actors on a much more different live spawn.

The bundle2 class may eventually grow bundle10 compatible method to 
automatically create parts containing the piece of changeset we need. 
That would be nice of him.

However those bundle10 compatibility method will be no use for the 
generic user of bundle2 (phases, bookmarks, obsmarkers). So current my 
focus is to build a minimalistic API that demonstrate the core of 
bundle2 feature: providing an extensible format containing parts. (and 
after that, generic infrastructure to process it)


> At the end of the day, we need to reach a state where most code in the
> push/pull path doesn't need to know or care if it's working with a
> bundle10 or later object.

Keep in mind that the part of push that does not deal with changeset is 
growing.

Current push path is:

A.1. Build changeset bundle
A.2. push that bundle through wire protocol
A.3  Analyse successfulnes
B.1. figure out phase change
B.2. push them with pushkey
B.3  Analyse successfulnes
C.1. pick obsmarker to send
C.2. push them with pushkey//evolve's stuff
D.3  Analyse successfulnes
D.1  figure out bookmark to move
D.2  move then with pushkey
D.3  Analyse successfulnes


This -cannot- be seamlessly switched to bundle2 with magic duck typing.

The introduction of bundle2 will change  toward this:
(disclaimer: this will not be the actual end result)

A.1. Figure what changeset to push
A.2. stick them into bundle
B.1. figure out phase change
B.2. try to stick them into bundle
C.1. pick marker to send
C.2. try to stick obsmarker into bundle
D.1. figure out bookmark to move
D.2. try to stick them into bundle
==== sending bundle2 over the wire
A.3. analyze changeset pushing success
B.3. analyze phase pushing success
C.3. analyse obsmaker pushing success
D.3. analyse bookmark move success

B.4 old style phase push if bundle2 did not supported them
C.4 old style obsmarker push if bundle2 did not supported them
D.4 old style bookmark move if bundle2 did not supported them

So having the ducktyping in bundle2 will help for the changeset but not 
for everything else.

In the exemple above we'll be helped by the fact all of phases. 
obsmarkers and bookmark use pushkey (for now). But you can then add 
extension like large file in mix and get the same kind of result.


My current plan is:

1. produce/consume a bundle2 container that contains parts
2. build the infrastructure to apply effect of part
3. make it available through wire protocol
4. use it in the push code
5. use it in the pull code
6. teach `hg bundle about it`

Each step should see significant improvement to the API.

The bundle10 ducktyping will most probably happen during step "(4) use 
it in the push code".

This step is unfortunately still a few week away


-- 
Pierre-Yves


More information about the Mercurial-devel mailing list