mirror of
https://github.com/facebook/sapling.git
synced 2024-10-10 08:47:12 +03:00
185bc0f437
Summary: With this new store, blobs will be transparently written to either an LFS store, or a non-LFS one, depending on their size. Initially, and as long as getpackv2 is supported, we also need to support parsing lfs pointer data that the server is sending and write these to the lfs pointer store. This code is very adhoc and does manual parsing of the pointer data, definitively not great, suggestion for a simple and better solution is welcome :). From a migration standpoint, the read-only LFS stores are added to the ContentStore, this allows blobs written in it to be readable at all time even when `remotefilelog.lfs` isn't set. The code will effecitvely be dormant for a while until the option is turned on, if we need to disable it, the dormant code will still be able to read all the blobs written to disk. This forces us to deploy a release that contains this code to stable first, before setting `remotefilelog.lfs`. Reviewed By: quark-zju Differential Revision: D19986878 fbshipit-source-id: 260f5a542d52e748c0c703bfa7bb8ffac0e7b388 |
||
---|---|---|
.. | ||
asyncrevisionstore/src | ||
auth | ||
backingstore | ||
blackbox | ||
bookmarkstore | ||
cdatapack | ||
clib | ||
clidispatch | ||
cliparser | ||
commitcloudsubscriber | ||
commitstore/bench-serialize | ||
configparser | ||
cpython-ext | ||
dag | ||
dev-logger | ||
drawdag | ||
edenapi | ||
edenfs-client | ||
encoding | ||
hgcommands | ||
hgtime | ||
indexedlog | ||
linelog | ||
lz4-pyframe | ||
manifest | ||
manifest-tree | ||
metalog | ||
mincode | ||
minibench | ||
minibytes | ||
mpatch | ||
mpatch-sys | ||
mutationstore | ||
nodemap | ||
pathmatcher | ||
procinfo | ||
radixbuf | ||
renderdag | ||
revisionstore | ||
stackdesc | ||
third-party | ||
thrift-types | ||
tracing-collector | ||
treestate | ||
types | ||
util | ||
vlqencoding | ||
workingcopy | ||
xdiff | ||
xdiff-sys | ||
zstdelta | ||
zstore | ||
CMakeLists.txt | ||
README.md |
lib
Any native code (C/C++/Rust) that Mercurial (either core or extensions)
depends on should go here. Python code, or native code that depends on
Python code (e.g. #include <Python.h>
or use cpython
) is disallowed.
As we start to convert more of Mercurial into Rust, and write new paths entrirely in native code, we'll want to limit our dependency on Python, which is why this barrier exists.
See also hgext/extlib/README.md
, mercurial/cext/README.mb
.
How do I choose between lib
and extlib
(and cext
)?
If your code is native and doesn't depend on Python (awesome!), it goes here.
Otherwise, put it in hgext/extlib
(if it's only used by extensions) or
mercurial/cext
(if it's used by extensions or core).