- User Since
- Jun 29 2017, 2:56 PM (169 w, 6 d)
That seems fine to me. We can battle with rustc to re-introducing the genericity when we actually need it.
I wanted the obsmarker. Which was not created (then my comment was wrong).
Tue, Sep 29
Mon, Sep 28
Sat, Sep 26
The logic looks good, but I hve a minor point on about the test.
Fri, Sep 25
tests/test-install.t and tests/test-duplicateoptions.py are unhappy about this change.
Thanks (but apparently you did created an obsmarker)
Thu, Sep 24
Wed, Sep 23
This looks fine
Now that a fix as landed in python 3.9 should we back this out ?
@Alphare gentle ping to provide a todo list here.
Fri, Sep 18
Thu, Sep 17
The behavior and the code looks good to me. I guess we should document the variable and the behavior somewhere. However I am not sure of where that might be. @yuya do you know where the chg documentation lives ?
Wed, Sep 16
Did you measure the performance impact on other operation than your target operation ? I am curious about the impact of the @property here.
Tue, Sep 15
Mon, Sep 14
Sat, Sep 12
looks good. As an unrelated change, maybe add a comment on the previous block to indicate it is relevant for all python starting from 3.9+
(maybe update the description to state this since this is a common question)
Sounds good then :-)
Fri, Sep 11
Does this affect all merge (especially hg merge) ? or just the one where the working copy has only one parent?
This kind of massive code block move in a huge function make me think we should slice it into smaller function. What do you think?
Why don't we get a test change with this ?
Thanks for the update.
not great, but okay.
(I wonder if we don't use "missing" more than "absent" through the code. However quick grepping is not very conclusive and "missing" could be confused with the hg status state)
Cf feedback on the previous changeset about the semantic of the message.
Looks good. Out of curiosity, did you do any performance measurement of this?
So right now the bid merge still behave in a bad way (delete the file instead of conflicting, but at least not it consistently does so regardless of where the merge is started?
thanks for the extensive documentation.
This looks fine.
Should we move this to change requested since this is WIP ?
(updating status to reflect the current discussion status)
The approach used by the nodemap is probably a good way forward for transactional case. Some kind of happen only index, that get recompacked on a regular basis. Combined with an append only data file (for example, children can be stored as linked list (data file size) with a pointer to the first entry in an index file.