[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