view .clang-format @ 40392:595641bd8404

sqlitestore: support for storing revisions without their parents This commit kinda/sorta implements the equivalent of ellipsis nodes for the SQLite storage backend. Without implementing full blown ellipsis nodes (and the necessary support for them in the wire protocol), we instead teach the store to rewrite the p1 and p2 nodes to nullid when the incoming parent isn't in the local store. This allows servers to remain dumb and send the real parent and have the clients deal with the missing parent problem. This obviously isn't ideal because a benefit of ellipsis nodes is we can insert a fake parent to ellide missing changesets. But neither solution is ideal because it drops the original parent from storage. We could probably teach the SQLite store to retain the original parent and handle missing parents at read time. However, parent revisions are stored as integers and it isn't trivial to store an "empty" revision in the store yet, which would be necessary to represent the "missing" parent. The store is somewhat intelligent in trying to remove the missing parents metadata when the revision is re-added. But, revision numbers will be all messed up in that case, so I'm not sure it is worth it. At some point we'll likely want to remove the concept of revision numbers from the database and have the store invent them at index generation time. Or even better, we can do away with revision numbers from the file storage interface completely. We'll get there eventually... Differential Revision: https://phab.mercurial-scm.org/D5168
author Gregory Szorc <gregory.szorc@gmail.com>
date Wed, 17 Oct 2018 17:32:15 +0200
parents d0a3fa849cb8
children
line wrap: on
line source

BasedOnStyle: LLVM
IndentWidth: 8
UseTab: ForIndentation
BreakBeforeBraces: Linux
AllowShortIfStatementsOnASingleLine: false
IndentCaseLabels: false
AllowShortBlocksOnASingleLine: false
AllowShortFunctionsOnASingleLine: false
IncludeCategories:
  - Regex:           '^<'
    Priority:        1
  - Regex:           '^"'
    Priority:        2