D1952: bundlespec: move computing the bundle contentops in parsebundlespec

[indygreg (Gregory Szorc)]

indygreg added a comment.


  I took a bit of a deeper look and found a few more things.
  
  Again, I like the direction of this patch. I think our goal for bundle2 generation should be to derive a set of options for its parts up front as quick as possible and pass that data structure into the lower-level bundle2 generation mechanism.

INLINE COMMENTS

> exchange.py:49-51
> +# Maps bundle version with content opts to choose which part to bundle
> +_bundlespeccontentops = {
> +    'v1': {

I *really* like this and this is the direction we need to go. i.e. a bundlespec base version should imply a set of options for generation of the bundle.

> exchange.py:89
>  
>      Returns a 3-tuple of (compression, version, parameters). Compression will
>      be ``None`` if not in strict mode and a compression isn't defined.

This comment needs updated.

> exchange.py:193
> +
> +    return compression, version, params, contentops
>  

At the point we're returning yet another element, it might be worth converting the return into an `attr`-derived class. We're starting to use those a bit to define data structures that are too large for tuples but don't yet merit a normal class.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1952

To: lothiraldan, #hg-reviewers, indygreg
Cc: indygreg, mercurial-devel