The dirstate map owns the nonnormal sets, and so should be the class to update
them. A future implementation of the dirstate will manage these maps
differently.
The action of clearing ambiguous times is now entirely controlled by the
dirstate map, so it moves there too.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
| mercurial/dirstate.py | ||
|---|---|---|
| 1286 | I would prefer to see all mutations to self._map go through a common code path so that we can override this behavior easier in Eden. As it stands, when this logic is conflated, it makes it much harder for us to safely subclass dirstatemap in Eden. For reference, here's what we're doing today: https://github.com/facebookexperimental/eden-hg/blob/master/eden/hg/eden/eden_dirstate_map.py | |
I strongly suspect that (if you agree with my feedback on D1340) this will need some adjustments to document the expanded behavior of dirstatemap WRT nonnormalset (whatever a nonnormalset is)
| mercurial/dirstate.py | ||
|---|---|---|
| 1286 | I think what you want is a common tuple constructor hook point - eden_dirstate_map does build a different tuple, but it just sets it as a property of the map in the same way. I think we want to avoid another layer of indirection if we can. Arguably dirstatetuple is already one of these, as it can be either a native tuple type, or the fast C-based one from parses.c, but maybe that's the wrong place for eden to hook as it's global to the module. Instead, we can do it by setting dirstatemap._tuplecls to dirstatetuple in the constructor, so the code here becomes more like: self._map[f] = self._tuplecls(state, mode, size, mtime) In eden you can make your own function and assign that to self._tuplecls in eden_dirstate_map.__init__. | |