D2593: state: add logic to parse the state file in old way if cbor fails

yuja (Yuya Nishihara) phabricator at mercurial-scm.org
Tue Mar 27 11:43:19 EDT 2018


yuja added inline comments.

INLINE COMMENTS

> martinvonz wrote in state.py:84
> Oh, and I should clarify that I think the root of the problem is that you're mixing the class for reading with state itself (but only the top-level items of it). Let's say someone realizes they want to iterate over the items in the state, would we also add a .items() then? (I don't think that's a likely scenario, but it shows what I mean.)

Sorry if it's already discussed, but what's the benefit of `cmdstate`
not being a plain dict?

I think plain load/save functions are much simpler than a dict-like object
backed by file, i.e.

  state = statemod.load(repo, fname)
  state = {'version': 1, 'nodes': nodelines}
  statemod.save(repo, fname, state)

(statemod.load/save could be a class for serialization/deserialization)

The state dict would be wrapped anyway depending on application logic.
If we can find out a common behavior between "state"s, we can extract it to a state class,
but that will still be separated from the storage format.

REPOSITORY
  rHG Mercurial

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

To: pulkit, #hg-reviewers
Cc: yuja, martinvonz, indygreg, durin42, mercurial-devel


More information about the Mercurial-devel mailing list