mirror of
https://github.com/facebook/sapling.git
synced 2024-10-11 17:27:53 +03:00
95eacecbfc
Summary: There was a bug where if a commit had an empty manifest (i.e. same contents as it's parents, but different p1/p2) and it resulted in a non-empty-but-still-a-noop delta in the revlog (i.e. a delta that deletes a line and replaces it with the same content), this resulted in a no-op set to the tree manifest. When the tree was serialized, it noticed that the set was a no-op, so it didn't serialize that particular tree, but the parent didn't get notified it was a no-op, so we serialized parent directories with pointers to sub trees that did not exist. The fix is to not store new sub-tree nodes on parents when the sub-tree contents are the same. Now we just store the original sub-tree node. So we no longer accidentally reference non-existent trees. Unfortunately I'm not sure how Mercurial can get into this situation (how do you produce a delta that has content, but the content is a no-op?), so I'm not sure how to test it. The tree verification command in another patch can catch this exception though. Test Plan: Ran 'hg debuggentrees' on a repo that has a manifest entry that exhibits this problem. Verified via the debugger that only one tree (the root node) was generated from adding that manifest. Reviewers: #mercurial, simonfar Reviewed By: simonfar Subscribers: simonfar, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4724539 Signature: t1:4724539:1489789531:02a9a75a85aa2a0a6e4c16e163867bd5a6f55670 |
||
|---|---|---|
| .. | ||
| convert.h | ||
| manifest_entry.cpp | ||
| manifest_entry.h | ||
| manifest_fetcher.cpp | ||
| manifest_fetcher.h | ||
| manifest.cpp | ||
| manifest.h | ||
| treemanifest.cpp | ||
| treemanifest.h | ||