facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-05 14:28:17 +03:00
Code Issues Projects Releases Wiki Activity

Edit EdenFS glossary doc grammar/spelling

Browse Source 
Summary: Minor changes to sentence structure, grammar, and spelling.

Reviewed By: genevievehelsel

Differential Revision: D32624350

fbshipit-source-id: 40a1dd3eae5df8adeaca05806a85ae20900a41f3
This commit is contained in:
Michael Cuevas 2021-11-29 11:03:31 -08:00 committed by Facebook GitHub Bot
parent 28f0ff9fc0
commit 52c167aa3f
1 changed files with 30 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
eden/fs/docs/Glossary.md
View File

@ -1,10 +1,12 @@
# EdenFS Glossary
### Backing Repository
The backing repository is the local on-disk source control
The backing repository is the local, on-disk, source control
[repository](#repository) from which EdenFS fetches source control data for a
[checkout](#checkout).
When fetching data from Mercurial or Git EdenFS require a separate local bare
When fetching data from Mercurial or Git, EdenFS requires a separate, local, bare
repository to be kept somewhere for EdenFS to use to fetch source control data.
This bare repository is the backing repository. Multiple checkouts can share
the same backing repository.
@ -14,7 +16,7 @@ the same backing repository.
The term backing store is sometimes used to refer to the underlying data source
used to fetch source control object information. This term comes from the
[`BackingStore`](../store/BackingStore.h) class which provides an API for
fetching data from source control. This is an abstract API which can in theory
fetching data from source control. This is an abstract API which can, in theory,
support multiple different source control types, such as EdenSCM, Mercurial, or
Git.
@ -23,7 +25,7 @@ option which may end up fetching data from a remote host.
The backing store generally refers to EdenFS's internal implementation for
fetching source control data. The [backing repository](#backing-repository) is
the concrete local on-disk storage of the underlying source control state.
the concrete, local, on-disk storage of the underlying source control state.
### Checkout
@ -50,7 +52,7 @@ of the term "checkout".
An inode represents a file or directory in the filesystem. This terminology is
common to Unix filesystems. The
[wikipedia entry](https://en.wikipedia.org/wiki/Inode) has a more complete
[inode wikipedia entry](https://en.wikipedia.org/wiki/Inode) has a more complete
description.
### Journal
@ -64,11 +66,11 @@ about recent filesystem changes.
The terms "loaded" and "unloaded" are used to refer to whether EdenFS has state
for a particular inode loaded in memory or not. If EdenFS has a `FileInode` or
`TreeInode` object in memory for a particular file or directory then that file
is referred to as loaded, otherwise it is unloaded.
`TreeInode` object in memory for a particular file or directory, then that file
is referred to as loaded. Otherwise, that file or directory is considered unloaded.
By default when a checkout is first mounted most inodes are unloaded, and
EdenFS lazily loads inodes on-demand as they are accessed.
By default, when a checkout is first mounted, most inodes are unloaded.
EdenFS then lazily loads inodes on-demand as they are accessed.
### Local Store
@ -83,15 +85,24 @@ to cache things in source control specific data structures when appropriate.
### Materialized / Non-Materialized
Inodes are considered materialized if we do not know a source control object ID
that that can be used to look up the file or directory contents. When a
checkout is first cloned all inodes are non-materialized, as we know that the
root directory corresponds to the root source control tree for the current
commit, and each of its children correspond to the its corresponding children
in source control.
that can be used to look up the file or directory contents. Non-materialized
inodes have contents identical to a source control object.
When a file is modified from its source control state it becomes materialized.
Brand new files that are created locally immediately start in the materialized
state. Materialized files are stored in the [overlay](#overlay).
When a checkout is first cloned, all inodes are non-materialized, as we know
that the root directory corresponds to the root source control tree for the
current commit. Each of its children correspond to its corresponding children
in source control, so they are also non-materialized.
When a file is modified from its source control state, it becomes materialized.
This is because we can no longer fetch the file contents from source control.
Following this logic, brand new files that are created locally immediately
start in the materialized state. Also, if a file no longer corresponds to a
known source control object, the parent directory also no longer corresponds to
a known source control tree. This means that when a child inode is
materialized, its ancestors are also materialized recursively upwards until the
root of the repo or an already materialized tree is reached.
Materialized files are stored in the [overlay](#overlay).
Non-materialized files do not need to be stored in the overlay, as their
contents can always be fetched from the source control repository.
@ -125,5 +136,5 @@ specifically to the working directory state.
The state directory is where EdenFS stores all of its local state. The
default location of this directory can be controlled in the system
configuration (`/etc/eden/edenfs.rc`) or the user-specific configuration
(`$HOME/.edenrc`), but it generally defaults to `$HOME/.eden/`. In some
Facebook environments it defaults to `$HOME/local/.eden`.
(`$HOME/.edenrc`), but it generally defaults to `$HOME/.eden/`. However,
it defaults to `$HOME/local/.eden` in some Meta environments.