Xavier Deguillard 74e48dfde3 treemanifest: delay packfile addition when using linkrev ... Summary: In order to provide fast "hg blame" for a file, Mercurial keeps an auxiliary data attached to every filenode: the linknode. This linknode is a backpointer to the revision that introduced the linknode. While the linknode allows for very fast blame, it also has a big drawback: the commit DAG has cycles. This makes for an awkward commit logic where the data needed by a commit also needs the commit hash. The solution that was taken up to now was to delay the write to the historypack until it's closed and use "linkrev" until then. By the time the historypack is closed the changelog will have been updated and the linkrev can be resolved to a valid linknode. The drawback of this solution is that the historypack (and other future stores) needs to have an understanding of what the changelog is to be able to interpret linkrevs. It also prevents the store from being able to blindly store data on disk as it is received. For now, let's solve this by moving the handling of linkrev one layer up, and recognizing when a linkrev is used and simply waiting until the changelog is updated before adding the resolved linknode to the historypack. A better solution to this problem is to simply not have a linknode in the historypack, and instead have an auxiliary file where linknodes are stored. This will remove the chicken-egg issue as this auxiliary file can be written after the changelog is updated. Most of the logic in this patch was inspired by a similar hack in remotefilelog. Reviewed By: DurhamG Differential Revision: D15684624 fbshipit-source-id: 578c42349d6c6f572ff578de0495f2e762814cd2		2019-06-17 14:01:30 -07:00
..
__init__.py	treemanifest: delay packfile addition when using linkrev	2019-06-17 14:01:30 -07:00