mbthomas added inline comments.

INLINE COMMENTS

> mbolin wrote in dirstate.py:1247
> 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 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__`.

REPOSITORY
  rHG Mercurial

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

To: mbthomas, #hg-reviewers
Cc: durin42, mbolin, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to