2016-09-10 02:56:02 +03:00
|
|
|
namespace cpp2 facebook.eden.overlay
|
|
|
|
|
|
|
|
typedef binary Hash
|
|
|
|
typedef string PathComponent
|
|
|
|
typedef string RelativePath
|
|
|
|
|
|
|
|
struct OverlayEntry {
|
|
|
|
// Holds the mode_t data, which encodes the file type and permissions
|
|
|
|
1: i32 mode
|
2017-02-11 01:16:00 +03:00
|
|
|
// The inodeNumber of the child, if it is materialized.
|
|
|
|
// If the child is not materialized this will be 0, and the hash will
|
|
|
|
// contain the hash of a source control Tree or Blob.
|
|
|
|
2: i64 inodeNumber
|
|
|
|
// If inodeNumber is 0, then this child is identical to an existing
|
|
|
|
// source control Tree or Blob. This contains the hash of that Tree or Blob.
|
|
|
|
3: Hash hash
|
2016-09-10 02:56:02 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
struct OverlayDir {
|
|
|
|
// The contents of this dir.
|
|
|
|
1: map<PathComponent, OverlayEntry> entries
|
|
|
|
// For a placeholder entry that is materialized in name only (for example,
|
|
|
|
// renaming a directory without materializing the entire content),
|
|
|
|
// the key that we will use to load the source TreeEntry when needed
|
|
|
|
2: Hash treeHash
|
|
|
|
}
|
|
|
|
|
|
|
|
struct OverlayData {
|
|
|
|
// A map of RelativePath -> OverlayDir for the entire contents of the
|
|
|
|
// overlay area. The assumption is that the locally materialized data
|
|
|
|
// (since it should be O(things-changed-in-1-diff) should reasonably
|
|
|
|
// fit in memory and thus that this won't be too big to work with.
|
|
|
|
1: map<RelativePath, OverlayDir> localDirs
|
|
|
|
}
|
Flip Dirstate -> EdenMount dependency.
Summary:
Previously, `Dirstate` took a `std::shared_ptr<EdenMount>`, but now it takes
pointers to a `MountPoint` and an `ObjectStore` because it does not need the
entire `EdenMount`. Ultimately, this will enable us to have `EdenMount` create
the `Dirstate` itself, but that will be done in a follow-up commit.
Fortunately, it was pretty easy to remove the references to `edenMount_` in
`Dirstate.cpp` and rewrite them in terms of `mountPoint_` or `objectStore_`.
The one thing that I also decided to move was `getModifiedDirectoriesForMount()`
because I already needed to create an `EdenMounts` file (admittedly not a
great name) to collect some utility functions that use members of an `EdenMount`
while not having access to the `EdenMount` itself.
As part of this change, all of the code in `eden/fs/model/hg` has been moved to
`eden/fs/inodes` so that it is alongside `EdenMount`. We are going to change
the `Dirstate` from an Hg-specific concept to a more general concept.
`LocalDirstatePersistence` is no longer one of two implementations of
`DirstatePersistence`. (The other was `FakeDirstatePersistence`.) Now there is
just one concrete implementation called `DirstatePersistence` that takes its
implementation from `LocalDirstatePersistence`. Because there is no longer a
`FakeDirstatePersistence`, `TestMount` must create a `DirstatePersistence` that
uses a `TemporaryFile`.
Because `TestMount` now takes responsibility for creating the `Dirstate`, it
must also give callers the ability to specify the user directives. To that end,
`TestMountBuilder` got an `addUserDirectives()` method while `TestMount` got a
`getDirstate()` method. Surprisingly, `TestMountTest` did not need to be updated
as part of this revision, but `DirstateTest` needed quite a few updates
(which were generally mechanical).
Reviewed By: simpkins
Differential Revision: D4230154
fbshipit-source-id: 9b8cb52b45ef5d75bc8f5e62a58fcd1cddc32bfa
2016-11-26 23:00:15 +03:00
|
|
|
|
|
|
|
enum UserStatusDirective {
|
|
|
|
Add = 0x0,
|
|
|
|
Remove = 0x1,
|
|
|
|
}
|
|
|
|
|
|
|
|
struct DirstateData {
|
|
|
|
1: map<RelativePath, UserStatusDirective> directives
|
|
|
|
}
|