A Scalable, User-Friendly Source Control System.
Go to file
Mark Thomas eef0c650e7 mutation: make the mutationstore the source of truth for mutation entries
Summary:
Previously the mutation commit extras were the source of truth for mutation
information, and the mutation store served as a kind of cache.  This turned out
to be less useful than expected, as oftentimes commits are missing, and the
store is better indexed, so in practice using the store as the source of truth
is better.

This change makes the mutationstore the (sole) source of truth for mutation
data.  The extras are kept, but they are now only useful as human-readable
debug information, and to ensure the commit hash is unique.

Collecting the mutation information during commit creation is now done through
a new `mutinfo` object.  This is a dict with the same keys as the mutation
extras, for simplicity, but it is now passed through the `committablectx` and
used to generate the mutation store entry directly.

The `mutation.enabled` config option is now used to control all aspects of
enabling mutation.

The `mutation.record` config option is now only used to indicate whether the
mutation extras should also added to the commit.  Generally this should be set
to `true`, however the option is retained so that mutation extras can be
stripped by running `hg amend --config mutation.record=false`, which no longer
has the side-effect of not recording mutation information to the store.

The "remote commit" mutation record origin is now obsolete, and won't be
generated anymore.

Pushrebase now relies on the obsmarker information coming back from the server
in order to correctly generate mutation information.  We will need to change
this so that the server returns mutation records before we can fully deprecate
obsmarkers.

Reviewed By: DurhamG

Differential Revision: D19410650

fbshipit-source-id: 8d7094e4bfd8d8e97916898d899a8debd339485f
2020-01-16 01:03:22 -08:00
build Updating submodules 2020-01-16 01:03:22 -08:00
CMake fix the dependencies for the Rust vendored crates 2019-12-06 11:59:47 -08:00
common deprecate copied stats headers that are now open sourced 2019-08-27 17:15:54 -07:00
eden mutation: make the mutationstore the source of truth for mutation entries 2020-01-16 01:03:22 -08:00
.gitignore eden: wire up mac contbuild 2019-02-05 21:52:30 -08:00
.travis.yml Remove sudo: required from .travis.yml (#37) 2019-07-24 08:55:03 -07:00
CMakeLists.txt add an option to also install the Python DLL on Windows 2020-01-13 16:10:57 -08:00
CODE_OF_CONDUCT.md Adopt Contributor Covenant 2019-08-29 23:23:31 -07:00
CONTRIBUTING.md relicense to GPLv2 2019-06-19 17:02:45 -07:00
getdeps.py Tidy up license headers 2019-10-11 05:28:23 -07:00
LICENSE relicense to GPLv2 2019-06-19 17:02:45 -07:00
make-client.py eden: use the zipapp_main instead of main so return code gets correctly returned 2019-12-03 09:20:42 -08:00
README.md Add CODE_OF_CONDUCT.md and reference the LICENSE file in README.md 2019-04-26 14:38:27 -07:00

EdenFS is a FUSE virtual filesystem for source control repositories.

EdenFS speeds up operations in large repositories by only populating working directory files on demand, as they are accessed. This makes operations like checkout much faster, in exchange for a small performance hit when first accessing new files. This is quite beneficial in large repositories where developers often only work with a small subset of the repository at a time.

EdenFS has similar performance advantages to using sparse checkouts, but a much better user experience. Unlike with sparse checkouts, EdenFS does not require manually curating the list of files to check out, and users can transparently access any file without needing to update the profile.

EdenFS also keeps track of which files have been modified, allowing very efficient status queries that do not need to scan the working directory. The filesystem monitoring tool Watchman also integrates with EdenFS, allowing it to more efficiently track updates to the filesystem.

Building EdenFS

EdenFS currently only builds on Linux. We have primarily tested building it on Ubuntu 18.04.

TL;DR

[eden]$ ./getdeps.py --system-deps
[eden]$ mkdir _build && cd _build
[eden/_build]$ cmake ..
[eden/_build]$ make

Dependencies

EdenFS depends on several other third-party projects. Some of these are commonly available as part of most Linux distributions, while others need to be downloaded and built from GitHub.

The getdeps.py script can be used to help download and build EdenFS's dependencies.

Operating System Dependencies

Running getdeps.py with --system-deps will make it install third-party dependencies available from your operating system's package management system. Without this argument it assumes you already have correct OS dependencies installed, and it only updates and builds dependencies that must be compiled from source.

GitHub Dependencies

By default getdeps.py will check out third-party dependencies into the eden/external/ directory, then build and install them into eden/external/install/

If repositories for some of the dependencies are already present in eden/external/ getdeps.py does not automatically fetch the latest upstream changes from GitHub. You can explicitly run ./getdeps.py --update if you want it to fetch the latest updates for each dependency and rebuild them from scratch.

License

See LICENSE.