This is an archive of the discontinued Mercurial Phabricator instance.

bundle: add the possibility to bundle a stream v2 part
ClosedPublic

Authored by lothiraldan on Jan 31 2018, 11:25 AM.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

lothiraldan created this revision.Jan 31 2018, 11:25 AM
lothiraldan updated this revision to Diff 5152.Feb 2 2018, 4:30 AM

Now that we have more time to review this series, this is the part I am the least comfortable with. I think we could/should extract the stream part generator somewhere else than exchange.py. Maybe bundle2.py directly but I'm not sure. Any ideas?

indygreg requested changes to this revision.Mar 19 2018, 4:39 PM
indygreg added a subscriber: indygreg.

Now that we have more time to review this series, this is the part I am the least comfortable with. I think we could/should extract the stream part generator somewhere else than exchange.py. Maybe bundle2.py directly but I'm not sure. Any ideas?

Yup. You've stumbled upon something: we have 2 variations of code that produce bundle2 data. We have bundle2._addpartsfromopts() and exchange.getbundlechunks(). There is redundancy between the two. For example, creation of the changegroup part.

I would *very* much like to see this code unified. Probably in bundle2.py. What makes it difficult to unify is that each implementation is determining *what data should I generate* via different mechanisms. bundle2.py is using a dict of [content] options. exchange.py is using bundle2 capabilities, which come from the client.

If you squint hard enough, these are both almost the same thing. I would like to think that we could normalize b2caps and content options down to a single data structure that described what to generate and we could pass that into a common *generate bundle2 content* function. I /think/ we want to unify on content options. But I'm not sure.

Things are a bit more difficult than they should be because bundle2 is both used for data at rest and in flight. It represents both static data and the request/results of an RPC call over the wire protocol. e.g. the check:*, error:*, and reply:* parts don't make a lot of sense for local-only bundle2 bundles. Those are there mainly to facilitate wire protocol features. So any unified *create a bundle* or *apply a bundle* functionality need to account for the fact that there are special bundle2 parts and functionality that are unique to the wire protocol.

Anyway, I'd fix the immediate concern of having to import exchange by moving the code for creating this bundle2 part into bundle2.py and having the part generator in exchange call into it.

This revision now requires changes to proceed.Mar 19 2018, 4:39 PM
lothiraldan updated this revision to Diff 7376.Mar 30 2018, 8:55 AM
indygreg accepted this revision.Mar 30 2018, 1:10 PM
This revision is now accepted and ready to land.Mar 30 2018, 1:10 PM
This revision was automatically updated to reflect the committed changes.