mirror of
https://github.com/facebook/sapling.git
synced 2024-10-07 07:17:55 +03:00
b4f3c70c6a
Summary: Historically, we have seen a number of messages like the following in the Eden logs: ``` Journal for .hg/blackbox.log holds invalid Created, Created sequence ``` Apparently we were getting these invalid sequences because we were not always recording a "rename" correctly. The "rename" constructor for a `JournalDelta` assumed that the source path should be included in the list of "removed" files while the destination path should be included in the list of "created" files. However, that is not accurate if the destination path already existed before the user ran `mv`. Fortunately, we already check whether the destination file exists in `TreeInode::doRename()`, so it is straightforward to determine whether the action is a "rename" (destination does not exist) or an "replace" (destination already exists) and then classify the destination path accordingly. As demonstrated by the new test introduced in this commit (`JournalUpdateTest::moveFileReplace`), in the old implementation, a file that was removed after it was overwritten would not show up as removed in the merged `JournalDelta`. Because Watchman relies on `JournalDelta::merge()` via the Thrift method `getFilesChangedSince()`, this would cause Watchman to report such a file as still existing even though it was removed. This definitely caused bugs in Nuclide. It is likely that other tools that rely on Watchman in Eden (such as Buck) may have also done incorrect things because of this bug, so this could explain past reported issues. Reviewed By: simpkins Differential Revision: D7888249 fbshipit-source-id: 3e57963f27c5421a6175d1a759db8d9597ed76f3 |
||
|---|---|---|
| .. | ||
| cli | ||
| docs | ||
| fs | ||
| hooks | ||
| integration | ||
| py | ||
| scripts | ||
| third-party | ||
| AUTODEPS | ||
| DEFS | ||
| Eden.project.toml | ||