( )⚙ D11488 dirstate: Don’t drop unrelated data in DirstateMap::set_entry

This is an archive of the discontinued Mercurial Phabricator instance.

dirstate: Don’t drop unrelated data in DirstateMap::set_entry
ClosedPublic

Authored by SimonSapin on Sep 22 2021, 4:55 PM.

Details

Summary

For example, copy source are handled separately. Removing it goes through
the copy_map_remove method (exposed to Python as .copymap.pop())

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

SimonSapin created this revision.Sep 22 2021, 4:55 PM

I'm surprised no tests were broken. Should there be a (unit) test?

This is called by dirstatemap.py:

  • In set_tracked when an entry already existed but wasn’t tracked (for example hg add just after hg rm)
  • In set_possibly_dirty
  • In __setitem__
  • (And in set_clean, but that one also calls copymap().pop(filename) anyway)

So my guess as to why no test was affected is that this isn’t called super often, and most tests don’t also check copy tracing information. It would be good to have a CLI-level integration test that’s affected by this but I don’t know how to make one. When and how are used copy source info stored in the dirstate?

I would not be in favor of adding dirstatemap.py unit tests (at least at the moment) because it’s an internal API that keep changing. As to a low-level unit test for this specific DirstateMap::set_entry Rust method, I feel it could only be trivial like "1. Do X 2. Check X is done" and not helpful at finding actual bugs. What matters here is what semantics are expected or not by callers.

It would be good to have a CLI-level integration test that’s affected by this but I don’t know how to make one. When and how are used copy source info stored in the dirstate?

When using hg move or hg copy, basically. It stores the copy information in the dirstate, and it gets committed at the next hg commit

I would not be in favor of adding dirstatemap.py unit tests (at least at the moment) because it’s an internal API that keep changing. As to a low-level unit test for this specific DirstateMap::set_entry Rust method, I feel it could only be trivial like "1. Do X 2. Check X is done" and not helpful at finding actual bugs. What matters here is what semantics are expected or not by callers.

Agreed.

Does that mean that a file can only ever have a copy source in the dirstate if it is in "added" state?

Does that mean that a file can only ever have a copy source in the dirstate if it is in "added" state?

No, because it can be marked as a copy after the fact with hg mv --after for example.

I’m struggling coming up with a test case that shows different behavior with this patch. I’ve found how to have copy_source != None for some dirstate nodes, but not what hg command can cause this set_entry method to be called for the same node after that.

Alphare accepted this revision.Sep 28 2021, 3:45 AM

I can't find anything obvious either, let's not waste any more time on this. Thanks!

This revision is now accepted and ready to land.Sep 28 2021, 3:45 AM