This method is not used yet. It saves to disk any mutation that was done to
the Repo’s dirstate through Repo::dirstate_map_mut. It takes care of
dirstate-v1 v.s. dirstate-v2, dockets, data files, appending when possible,
etc.
Details
- Reviewers
Alphare - Group Reviewers
hg-reviewers - Commits
- rHG2097f63575a5: rhg: Add Repo::write_dirstate
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
rust/hg-core/src/repo.rs | ||
---|---|---|
429 | +1 for a WritableRepo that requires the lock in a future patch | |
451 | This should support HGTEST_UUIDFILE (see mercurial/revlogutils/docket.py) otherwise some tests will end up failing. Possibly this chould just be a TODO, but I'd rather at least detect the env variable and print a warning to stderr that its support isn't implemented, so that it's more obvious down the line. | |
rust/hg-core/src/revlog/node.rs | ||
178 | Cool method |
rust/hg-core/src/repo.rs | ||
---|---|---|
451 | https://foss.heptapod.net/mercurial/mercurial-devel/-/jobs/271544 shows that no test fail because of this. As far as I understand, this point of HGTEST_UUIDFILE is to have deterministic data filenames for nodemap dockets so it’s less annoying to add glob patterns everywhere in expected test ouptput what it includes these names. But this new Rust code is only used to generate dirstate data filenames which are not printed in tests. To port the current exact behavior of docket.py we’d need to have the same PRNG algorithm as Python’s random.Random(). Instead we could probably change docket.py to use a known, fixed PRNG algorithm. I’ll probably stick with the warning for now. By stderr do you mean literally using std::eprintln!, or should we start passing around a &Ui value everywhere? |
rust/hg-core/src/repo.rs | ||
---|---|---|
451 |
The env variable is always set by run-tests.py, so a warning would affect the output of every single test where hg status writes dirstate updates. So if a warning exists the only practical thing for tests would be to silence it, but that’s the only place where it would happen. I’ll add a TODO comment and no warning. |
+1 for a WritableRepo that requires the lock in a future patch