2019-03-08 06:29:53 +03:00
|
|
|
/*
|
2019-06-20 02:58:25 +03:00
|
|
|
* Copyright (c) Facebook, Inc. and its affiliates.
|
2019-03-08 06:29:53 +03:00
|
|
|
*
|
2019-06-20 02:58:25 +03:00
|
|
|
* This software may be used and distributed according to the terms of the
|
|
|
|
* GNU General Public License version 2.
|
2019-03-08 06:29:53 +03:00
|
|
|
*/
|
2019-10-11 15:26:59 +03:00
|
|
|
|
2019-06-11 22:59:03 +03:00
|
|
|
include "eden/fs/config/eden_config.thrift"
|
2019-07-25 07:04:08 +03:00
|
|
|
include "fb303/thrift/fb303_core.thrift"
|
2016-05-12 23:43:17 +03:00
|
|
|
|
|
|
|
namespace cpp2 facebook.eden
|
2016-08-18 17:21:36 +03:00
|
|
|
namespace java com.facebook.eden.thrift
|
2016-05-12 23:43:17 +03:00
|
|
|
namespace py facebook.eden
|
2020-06-05 01:14:46 +03:00
|
|
|
namespace py3 eden.fs.service
|
2016-05-12 23:43:17 +03:00
|
|
|
|
2016-09-19 22:48:12 +03:00
|
|
|
/** Thrift doesn't really do unsigned numbers, but we can sort of fake it.
|
|
|
|
* This type is serialized as an integer value that is 64-bits wide and
|
|
|
|
* should round-trip with full fidelity for C++ client/server, but for
|
|
|
|
* other runtimes will have crazy results if the sign bit is ever set.
|
|
|
|
* In practice it is impossible for us to have files that large in eden,
|
|
|
|
* and sequence numbers will take an incredibly long time to ever roll
|
|
|
|
* over and cause problems.
|
|
|
|
* Once t13345978 is done, we can uncomment the cpp.type below.
|
|
|
|
*/
|
|
|
|
typedef i64 /* (cpp.type = "std::uint64_t") */ unsigned64
|
|
|
|
|
2018-09-10 23:42:12 +03:00
|
|
|
typedef i32 pid_t
|
|
|
|
|
2017-02-22 23:19:04 +03:00
|
|
|
/**
|
2018-03-21 02:34:01 +03:00
|
|
|
* A source control hash.
|
|
|
|
*
|
|
|
|
* This should normally be a 20-byte binary value, however the edenfs server
|
|
|
|
* will accept BinaryHash arguments as 40-byte hexadecimal strings as well.
|
|
|
|
* Data returned by the edenfs server in a BinaryHash field will always be a
|
|
|
|
* 20-byte binary value.
|
2017-02-22 23:19:04 +03:00
|
|
|
*/
|
|
|
|
typedef binary BinaryHash
|
|
|
|
|
2018-08-11 11:34:44 +03:00
|
|
|
/**
|
|
|
|
* So, you thought that a path was a string?
|
|
|
|
* Paths in posix are arbitrary byte strings with some pre-defined special
|
|
|
|
* characters. On modern systems they tend to be represented as UTF-8 but
|
|
|
|
* there is no guarantee. We use the `PathString` type as symbolic way
|
|
|
|
* to indicate that you may need to perform special processing to safely
|
|
|
|
* interpret the path data on your system.
|
|
|
|
*/
|
|
|
|
typedef binary PathString
|
|
|
|
|
2019-10-29 19:20:57 +03:00
|
|
|
/**
|
|
|
|
* A customizable type to be returned with an EdenError, helpful for catching
|
|
|
|
* and having custom client logic to handle specfic error cases
|
|
|
|
*/
|
|
|
|
enum EdenErrorType {
|
|
|
|
/** The errorCode property is a posix errno value */
|
|
|
|
POSIX_ERROR = 0,
|
|
|
|
/** The errorCode property is a win32 error value */
|
|
|
|
WIN32_ERROR = 1,
|
|
|
|
/** The errorCode property is a windows NT HResult error value */
|
|
|
|
HRESULT_ERROR = 2,
|
|
|
|
/**
|
|
|
|
* An argument passed to thrift was invalid. errorCode will be set to EINVAL
|
|
|
|
*/
|
|
|
|
ARGUMENT_ERROR = 3,
|
|
|
|
/** An error occurred. errorCode will be not set */
|
|
|
|
GENERIC_ERROR = 4,
|
|
|
|
/** The mount generation changed. errorCode will be set to ERANGE */
|
|
|
|
MOUNT_GENERATION_CHANGED = 5,
|
|
|
|
/** The journal has been truncated. errorCode will be set to EDOM */
|
|
|
|
JOURNAL_TRUNCATED = 6,
|
|
|
|
/**
|
|
|
|
* The thrift funtion that receives this in an error is being called while
|
|
|
|
* a checkout is in progress. errorCode will not be set.
|
|
|
|
*/
|
|
|
|
CHECKOUT_IN_PROGRESS = 7,
|
|
|
|
/**
|
|
|
|
* The thrift function that receives this is an error is being called with a
|
|
|
|
* parent that is not the current parent. errorCode will not be set.
|
|
|
|
*/
|
|
|
|
OUT_OF_DATE_PARENT = 8,
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
exception EdenError {
|
2016-05-28 04:16:27 +03:00
|
|
|
1: required string message
|
|
|
|
2: optional i32 errorCode
|
2019-10-29 19:20:57 +03:00
|
|
|
3: EdenErrorType errorType
|
2016-05-12 23:43:17 +03:00
|
|
|
} (message = 'message')
|
|
|
|
|
2017-09-11 20:37:13 +03:00
|
|
|
exception NoValueForKeyError {
|
|
|
|
1: string key
|
|
|
|
}
|
2016-05-12 23:43:17 +03:00
|
|
|
|
2019-07-17 23:43:32 +03:00
|
|
|
/**
|
|
|
|
* Information about the running edenfs daemon.
|
|
|
|
*/
|
|
|
|
struct DaemonInfo {
|
|
|
|
1: i32 pid
|
|
|
|
/**
|
|
|
|
* List of command line arguments, including the executable name,
|
|
|
|
* given to the edenfs process.
|
|
|
|
*/
|
|
|
|
2: list<string> commandLine
|
2020-02-27 08:00:52 +03:00
|
|
|
/**
|
|
|
|
* The service status.
|
|
|
|
* This is the same data reported by fb303_core.getStatus()
|
|
|
|
*/
|
|
|
|
3: optional fb303_core.fb303_status status
|
2020-05-11 21:39:23 +03:00
|
|
|
/**
|
|
|
|
* The uptime of the edenfs daemon
|
|
|
|
* Same data from /proc/pid/stat
|
|
|
|
* This will not be populated in Windows build
|
|
|
|
*/
|
|
|
|
4: optional float uptime
|
2019-07-17 23:43:32 +03:00
|
|
|
}
|
|
|
|
|
2019-01-02 23:55:02 +03:00
|
|
|
/**
|
|
|
|
* The current running state of an EdenMount.
|
|
|
|
*/
|
|
|
|
enum MountState {
|
|
|
|
/**
|
2019-01-17 06:32:38 +03:00
|
|
|
* The EdenMount object has been constructed but has not started
|
|
|
|
* initializing.
|
2019-01-02 23:55:02 +03:00
|
|
|
*/
|
|
|
|
UNINITIALIZED = 0,
|
2019-01-17 06:32:38 +03:00
|
|
|
/**
|
|
|
|
* The mount point is currently initializing and loading necessary state
|
|
|
|
* (such as the root directory contents) before it can ask the kernel to
|
|
|
|
* mount it.
|
|
|
|
*/
|
|
|
|
INITIALIZING = 1,
|
|
|
|
/**
|
|
|
|
* The mount point has loaded its local state needed to start mounting
|
|
|
|
* but has not actually started mounting yet.
|
|
|
|
*/
|
|
|
|
INITIALIZED = 2,
|
2019-01-02 23:55:02 +03:00
|
|
|
/**
|
|
|
|
* Starting to mount fuse.
|
|
|
|
*/
|
|
|
|
STARTING = 3,
|
|
|
|
/**
|
|
|
|
* The EdenMount is running normally.
|
|
|
|
*/
|
|
|
|
RUNNING = 4,
|
|
|
|
/**
|
|
|
|
* Encountered an error while starting fuse mount.
|
|
|
|
*/
|
|
|
|
FUSE_ERROR = 5,
|
|
|
|
/**
|
|
|
|
* EdenMount::shutdown() has been called, but it is not complete yet.
|
|
|
|
*/
|
|
|
|
SHUTTING_DOWN = 6,
|
|
|
|
/**
|
|
|
|
* EdenMount::shutdown() has completed, but there are still outstanding
|
|
|
|
* references so EdenMount::destroy() has not been called yet.
|
|
|
|
*
|
|
|
|
* When EdenMount::destroy() is called the object can be destroyed
|
|
|
|
* immediately.
|
|
|
|
*/
|
|
|
|
SHUT_DOWN = 7,
|
|
|
|
/**
|
|
|
|
* EdenMount::destroy() has been called, but the shutdown is not complete
|
|
|
|
* yet. There are no remaining references to the EdenMount at this point,
|
|
|
|
* so when the shutdown completes it will be automatically destroyed.
|
|
|
|
*/
|
|
|
|
DESTROYING = 8,
|
2019-08-01 06:06:21 +03:00
|
|
|
/**
|
|
|
|
* An error occurred during mount initialization.
|
|
|
|
*
|
|
|
|
* This state is used for errors that occur during the INITIALIZING phase,
|
|
|
|
* before we have attempted to start the FUSE mount.
|
|
|
|
*/
|
|
|
|
INIT_ERROR = 9,
|
2019-01-02 23:55:02 +03:00
|
|
|
} (cpp2.enum_type = 'uint32_t')
|
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
struct MountInfo {
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint
|
|
|
|
2: PathString edenClientPath
|
2019-01-02 23:55:02 +03:00
|
|
|
3: MountState state
|
|
|
|
}
|
|
|
|
|
|
|
|
struct MountArgument {
|
|
|
|
1: PathString mountPoint
|
|
|
|
2: PathString edenClientPath
|
2020-03-12 07:36:11 +03:00
|
|
|
3: bool readOnly
|
2016-05-12 23:43:17 +03:00
|
|
|
}
|
|
|
|
|
2016-08-18 17:21:36 +03:00
|
|
|
union SHA1Result {
|
2017-02-22 23:19:04 +03:00
|
|
|
1: BinaryHash sha1
|
2016-08-18 17:21:36 +03:00
|
|
|
2: EdenError error
|
|
|
|
}
|
|
|
|
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* Effectively a `struct timespec`
|
|
|
|
*/
|
2016-09-19 22:48:09 +03:00
|
|
|
struct TimeSpec {
|
|
|
|
1: i64 seconds
|
|
|
|
2: i64 nanoSeconds
|
|
|
|
}
|
|
|
|
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
2020-04-28 07:48:44 +03:00
|
|
|
* Information about filesystem entries that can be retrieved solely
|
|
|
|
* from the tree structure, without having to fetch the actual child
|
|
|
|
* objects from source control.
|
|
|
|
*/
|
|
|
|
struct EntryInformation {
|
2020-04-28 23:19:10 +03:00
|
|
|
1: Dtype dtype
|
2020-04-28 07:48:44 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
union EntryInformationOrError {
|
|
|
|
1: EntryInformation info
|
|
|
|
2: EdenError error
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Subset of stat() data returned from getFileInformation())
|
2017-04-04 01:47:53 +03:00
|
|
|
*/
|
2016-09-19 22:48:09 +03:00
|
|
|
struct FileInformation {
|
2016-09-19 22:48:12 +03:00
|
|
|
1: unsigned64 size // wish thrift had unsigned numbers
|
2016-09-19 22:48:09 +03:00
|
|
|
2: TimeSpec mtime
|
|
|
|
3: i32 mode // mode_t
|
|
|
|
}
|
|
|
|
|
2016-09-19 22:48:12 +03:00
|
|
|
/** Holds information about a file, or an error in retrieving that info.
|
|
|
|
* The most likely error will be ENOENT, implying that the file doesn't exist.
|
|
|
|
*/
|
|
|
|
union FileInformationOrError {
|
|
|
|
1: FileInformation info
|
|
|
|
2: EdenError error
|
|
|
|
}
|
|
|
|
|
|
|
|
/** reference a point in time in the journal.
|
|
|
|
* This can be used to reason about a point in time in a given mount point.
|
2016-09-19 22:48:14 +03:00
|
|
|
* The mountGeneration value is opaque to the client.
|
2016-09-19 22:48:12 +03:00
|
|
|
*/
|
|
|
|
struct JournalPosition {
|
|
|
|
/** An opaque but unique number within the scope of a given mount point.
|
|
|
|
* This is used to determine when sequenceNumber has been invalidated. */
|
2016-09-19 22:48:14 +03:00
|
|
|
1: i64 mountGeneration
|
2016-09-19 22:48:12 +03:00
|
|
|
|
|
|
|
/** Monotonically incrementing number
|
|
|
|
* Each journalled change causes this number to increment. */
|
|
|
|
2: unsigned64 sequenceNumber
|
|
|
|
|
|
|
|
/** Records the snapshot hash at the appropriate point in the journal */
|
2017-04-28 03:30:14 +03:00
|
|
|
3: BinaryHash snapshotHash
|
2016-09-19 22:48:12 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Holds information about a set of paths that changed between two points.
|
|
|
|
* fromPosition, toPosition define the time window.
|
|
|
|
* paths holds the list of paths that changed in that window.
|
2018-08-16 00:43:28 +03:00
|
|
|
*
|
|
|
|
* This type is quasi-deprecated. It has multiple API problems and should be
|
|
|
|
* rethought when we have a chance to make a breaking change.
|
2016-09-19 22:48:12 +03:00
|
|
|
*/
|
|
|
|
struct FileDelta {
|
|
|
|
/** The fromPosition passed to getFilesChangedSince */
|
|
|
|
1: JournalPosition fromPosition
|
|
|
|
/** The current position at the time that getFilesChangedSince was called */
|
|
|
|
2: JournalPosition toPosition
|
2018-08-16 00:43:28 +03:00
|
|
|
/** The union of changedPaths and createdPaths contains the total set of paths
|
|
|
|
* changed in the overlay between fromPosition and toPosition.
|
|
|
|
* Disjoint with createdPaths.
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
3: list<PathString> changedPaths
|
2018-08-16 00:43:28 +03:00
|
|
|
/** The set of paths created between fromPosition and toPosition.
|
|
|
|
* Used by Watchman to search for cookies and to populate its 'new' field.
|
|
|
|
* Disjoint with changedPaths.
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
4: list<PathString> createdPaths
|
2018-08-16 00:43:28 +03:00
|
|
|
/** Deprecated - always empty. */
|
2018-08-11 11:34:44 +03:00
|
|
|
5: list<PathString> removedPaths
|
2017-10-17 08:22:18 +03:00
|
|
|
/** When fromPosition.snapshotHash != toPosition.snapshotHash this holds
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
* the union of the set of files whose ScmFileStatus differed from the
|
2017-10-17 08:22:18 +03:00
|
|
|
* committed fromPosition hash before the hash changed, and the set of
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
* files whose ScmFileStatus differed from the committed toPosition hash
|
2017-10-17 08:22:18 +03:00
|
|
|
* after the hash was changed. This list of files represents files
|
|
|
|
* whose state may have changed as part of an update operation, but
|
|
|
|
* in ways that may not be able to be extracted solely by performing
|
|
|
|
* source control diff operations on the from/to hashes. */
|
2018-08-11 11:34:44 +03:00
|
|
|
6: list<PathString> uncleanPaths
|
2016-09-19 22:48:12 +03:00
|
|
|
}
|
|
|
|
|
2018-05-23 11:27:16 +03:00
|
|
|
struct DebugGetRawJournalParams {
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint
|
2019-07-09 19:10:19 +03:00
|
|
|
2: optional i32 limit
|
|
|
|
3: i32 fromSequenceNumber
|
2018-05-23 11:27:16 +03:00
|
|
|
}
|
|
|
|
|
2018-08-16 00:43:28 +03:00
|
|
|
struct DebugPathChangeInfo {
|
|
|
|
1: bool existedBefore
|
|
|
|
2: bool existedAfter
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A fairly direct modeling of the underlying JournalDelta data structure.
|
|
|
|
*/
|
|
|
|
struct DebugJournalDelta {
|
|
|
|
1: JournalPosition fromPosition
|
|
|
|
2: JournalPosition toPosition
|
|
|
|
3: map<PathString, DebugPathChangeInfo> changedPaths
|
|
|
|
4: set<PathString> uncleanPaths
|
|
|
|
}
|
|
|
|
|
2018-05-23 11:27:16 +03:00
|
|
|
struct DebugGetRawJournalResponse {
|
2018-08-16 00:43:28 +03:00
|
|
|
2: list<DebugJournalDelta> allDeltas
|
2018-05-23 11:27:16 +03:00
|
|
|
}
|
|
|
|
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
/**
|
|
|
|
* Classifies the change of the state of a file between and old and new state
|
|
|
|
* of the repository. Most commonly, the "old state" is the parent commit while
|
|
|
|
* the "new state" is the working copy.
|
|
|
|
*/
|
|
|
|
enum ScmFileStatus {
|
|
|
|
/**
|
|
|
|
* File is present in the new state, but was not present in old state.
|
|
|
|
*/
|
|
|
|
ADDED = 0x0,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* File is present in both the new and old states, but its contents or
|
|
|
|
* file permissions have changed.
|
|
|
|
*/
|
2016-11-26 23:00:16 +03:00
|
|
|
MODIFIED = 0x1,
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* File was present in the old state, but is not present in the new state.
|
|
|
|
*/
|
|
|
|
REMOVED = 0x2,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* File is present in the new state, but it is ignored according to the rules
|
|
|
|
* of the new state.
|
|
|
|
*/
|
|
|
|
IGNORED = 0x3,
|
2016-11-26 23:00:16 +03:00
|
|
|
}
|
|
|
|
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
struct ScmStatus {
|
2018-08-11 11:34:44 +03:00
|
|
|
1: map<PathString, ScmFileStatus> entries
|
2018-03-21 02:34:03 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A map of { path -> error message }
|
|
|
|
*
|
|
|
|
* If any errors occured while computing the diff they will be reported here.
|
|
|
|
* The results listed in the entries field may not be accurate for any paths
|
|
|
|
* listed in this error field.
|
|
|
|
*
|
|
|
|
* This map will be empty if no errors occurred.
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
2: map<PathString, string> errors
|
2016-11-26 23:00:16 +03:00
|
|
|
}
|
|
|
|
|
Change how the UNTRACKED_ADDED conflict and merges are handled.
Summary:
Previously, we used the Mercurial code `g` when faced with an `UNTRACKED_ADDED`
file conflict, but that was allowing merges to silently succeed that should not
have. This revision changes our logic to use the code `m` for merge, which
unearthed that we were not honoring the user's `update.check` setting properly.
Because we use `update.check=noconflict` internally at Facebook, we changed the
Eden integration tests to default to verifying Hg running with this setting. To
support it properly, we had to port this code from `update.py` in Mercurial to
our own `_determine_actions_for_conflicts()` function:
```
if updatecheck == 'noconflict':
for f, (m, args, msg) in actionbyfile.iteritems():
if m not in ('g', 'k', 'e', 'r', 'pr'):
msg = _("conflicting changes")
hint = _("commit or update --clean to discard changes")
raise error.Abort(msg, hint=hint)
```
However, this introduced an interesting issue where the `checkOutRevision()`
Thrift call from Hg would update the `SNAPSHOT` file on the server, but
`.hg/dirstate` would not get updated with the new parents until the update
completed on the client. With the new call to `raise error.Abort` on the client,
we could get in a state where the `SNAPSHOT` file had the hash of the commit
assuming the update succeeded, but `.hg/dirstate` reflected the reality where it
failed.
To that end, we changed `checkOutRevision()` to take a new parameter,
`checkoutMode`, which can take on one of three values: `NORMAL`, `DRY_RUN`, and
`FORCE`. Now if the user tries to do an ordinary `hg update` with
`update.check=noconflict`, we first do a `DRY_RUN` and examine the potential
conflicts. Only if the conflicts should not block the update do we proceed with
a call to `checkOutRevision()` in `NORMAL` mode.
To make this work, we had to make a number of changes to `CheckoutAction`,
`CheckoutContext`, `EdenMount`, and `TreeInode` to keep track of the
`checkoutMode` and ensure that no changes are made to the working copy when a
`DRY_RUN` is in effect.
One minor issue (for which there is a `TODO`) is that a `DRY_RUN` will not
report any `DIRECTORY_NOT_EMPTY` conflicts that may exist. As `TreeInode` is
implemented today, it is a bit messy to report this type of conflict without
modifying the working copy along the way.
Finally, any `UNTRACKED_ADDED` conflict should cause an update to
abort to match the behavior in stock Mercurial if the user has the following
config setting:
```
[commands]
update.check = noconflict
```
Though the original name for this setting was:
```
[experimental]
updatecheck = noconflict
```
Although I am on Mercurial 4.4.1, the `update.check` setting does not seem to
take effect when I run the integration tests, but the `updatecheck` setting
does, so for now, I set both in `hg_extension_test_base.py` with a `TODO` to
remove `updatecheck` once I can get `update.check` to do its job.
Reviewed By: simpkins
Differential Revision: D6366007
fbshipit-source-id: bb3ecb1270e77d59d7d9e7baa36ada61971bbc49
2017-11-30 08:38:12 +03:00
|
|
|
/** Option for use with checkOutRevision(). */
|
|
|
|
enum CheckoutMode {
|
|
|
|
/**
|
|
|
|
* Perform a "normal" checkout, analogous to `hg checkout` in Mercurial. Files
|
|
|
|
* in the working copy will be changed to reflect the destination snapshot,
|
|
|
|
* though files with conflicts will not be modified.
|
|
|
|
*/
|
|
|
|
NORMAL = 0,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Do not checkout: exercise the checkout logic to discover potential
|
|
|
|
* conflicts.
|
|
|
|
*/
|
|
|
|
DRY_RUN = 1,
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Perform a "forced" checkout, analogous to `hg checkout --clean` in
|
|
|
|
* Mercurial. Conflicts between the working copy and destination snapshot will
|
|
|
|
* be forcibly ignored in favor of the state of the new snapshot.
|
|
|
|
*/
|
|
|
|
FORCE = 2,
|
|
|
|
}
|
|
|
|
|
2017-02-16 07:31:48 +03:00
|
|
|
enum ConflictType {
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* We failed to update this particular path due to an error
|
|
|
|
*/
|
2017-05-08 23:49:17 +03:00
|
|
|
ERROR = 0,
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* A locally modified file was deleted in the new Tree
|
|
|
|
*/
|
2017-05-08 23:49:17 +03:00
|
|
|
MODIFIED_REMOVED = 1,
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* An untracked local file exists in the new Tree
|
|
|
|
*/
|
2017-05-08 23:49:17 +03:00
|
|
|
UNTRACKED_ADDED = 2,
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* The file was removed locally, but modified in the new Tree
|
|
|
|
*/
|
2017-05-08 23:49:17 +03:00
|
|
|
REMOVED_MODIFIED = 3,
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* The file was removed locally, and also removed in the new Tree.
|
|
|
|
*/
|
2017-05-08 23:49:17 +03:00
|
|
|
MISSING_REMOVED = 4,
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* A locally modified file was modified in the new Tree
|
|
|
|
* This may be contents modifications, or a file type change (directory to
|
|
|
|
* file or vice-versa), or permissions changes.
|
|
|
|
*/
|
2017-09-22 02:52:13 +03:00
|
|
|
MODIFIED_MODIFIED = 5,
|
2017-04-04 01:47:53 +03:00
|
|
|
/**
|
|
|
|
* A directory was supposed to be removed or replaced with a file,
|
|
|
|
* but it contains untracked files preventing us from updating it.
|
|
|
|
*/
|
2017-05-08 23:49:17 +03:00
|
|
|
DIRECTORY_NOT_EMPTY = 6,
|
2017-02-16 07:31:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Details about conflicts or errors that occurred during a checkout operation
|
|
|
|
*/
|
|
|
|
struct CheckoutConflict {
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString path
|
2017-02-16 07:31:48 +03:00
|
|
|
2: ConflictType type
|
|
|
|
3: string message
|
|
|
|
}
|
|
|
|
|
2017-04-04 01:47:53 +03:00
|
|
|
struct ScmBlobMetadata {
|
|
|
|
1: i64 size
|
|
|
|
2: BinaryHash contentsSha1
|
|
|
|
}
|
|
|
|
|
|
|
|
struct ScmTreeEntry {
|
|
|
|
1: binary name
|
|
|
|
2: i32 mode
|
|
|
|
3: BinaryHash id
|
|
|
|
}
|
|
|
|
|
|
|
|
struct TreeInodeEntryDebugInfo {
|
|
|
|
/**
|
|
|
|
* The entry name. This is just a PathComponent, not the full path
|
|
|
|
*/
|
|
|
|
1: binary name
|
|
|
|
/**
|
|
|
|
* The inode number, or 0 if no inode number has been assigned to
|
|
|
|
* this entry
|
|
|
|
*/
|
|
|
|
2: i64 inodeNumber
|
|
|
|
/**
|
|
|
|
* The entry mode_t value
|
|
|
|
*/
|
|
|
|
3: i32 mode
|
|
|
|
/**
|
|
|
|
* True if an InodeBase object exists for this inode or not.
|
|
|
|
*/
|
|
|
|
4: bool loaded
|
|
|
|
/**
|
|
|
|
* True if an the inode is materialized in the overlay
|
|
|
|
*/
|
|
|
|
5: bool materialized
|
|
|
|
/**
|
|
|
|
* If materialized is false, hash contains the ID of the underlying source
|
|
|
|
* control Blob or Tree.
|
|
|
|
*/
|
|
|
|
6: BinaryHash hash
|
2019-08-29 19:08:00 +03:00
|
|
|
/**
|
|
|
|
* Size of the file in bytes, won't be set for directories
|
|
|
|
*/
|
|
|
|
7: optional i64 fileSize
|
2017-04-04 01:47:53 +03:00
|
|
|
}
|
|
|
|
|
2017-04-28 03:30:14 +03:00
|
|
|
struct WorkingDirectoryParents {
|
|
|
|
1: BinaryHash parent1
|
|
|
|
2: optional BinaryHash parent2
|
|
|
|
}
|
|
|
|
|
2017-04-04 01:47:53 +03:00
|
|
|
struct TreeInodeDebugInfo {
|
|
|
|
1: i64 inodeNumber
|
|
|
|
2: binary path
|
|
|
|
3: bool materialized
|
|
|
|
4: BinaryHash treeHash
|
|
|
|
5: list<TreeInodeEntryDebugInfo> entries
|
2017-06-23 08:33:01 +03:00
|
|
|
6: i64 refcount
|
2017-04-04 01:47:53 +03:00
|
|
|
}
|
|
|
|
|
2017-08-17 05:56:32 +03:00
|
|
|
struct InodePathDebugInfo {
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString path
|
2017-08-17 05:56:32 +03:00
|
|
|
2: bool loaded
|
2017-08-25 18:24:43 +03:00
|
|
|
3: bool linked
|
2017-08-17 05:56:32 +03:00
|
|
|
}
|
|
|
|
|
2017-10-25 19:38:07 +03:00
|
|
|
struct SetLogLevelResult {
|
|
|
|
1: bool categoryCreated
|
|
|
|
}
|
|
|
|
|
2019-06-07 23:33:49 +03:00
|
|
|
struct JournalInfo {
|
|
|
|
1: i64 entryCount
|
2019-06-29 02:37:43 +03:00
|
|
|
// The estimated memory used by the journal in bytes
|
2019-06-07 23:33:49 +03:00
|
|
|
2: i64 memoryUsage
|
2019-06-29 02:37:43 +03:00
|
|
|
// The duration of the journal in seconds
|
|
|
|
3: i64 durationSeconds
|
2019-06-07 23:33:49 +03:00
|
|
|
}
|
|
|
|
|
2017-08-25 22:41:41 +03:00
|
|
|
/**
|
|
|
|
* Struct to store Information about inodes in a mount point.
|
|
|
|
*/
|
|
|
|
struct MountInodeInfo {
|
|
|
|
2: i64 unloadedInodeCount
|
2018-01-25 02:18:47 +03:00
|
|
|
4: i64 loadedFileCount
|
|
|
|
5: i64 loadedTreeCount
|
2017-08-25 22:41:41 +03:00
|
|
|
}
|
|
|
|
|
2018-12-07 06:25:38 +03:00
|
|
|
struct CacheStats {
|
|
|
|
1: i64 entryCount
|
|
|
|
2: i64 totalSizeInBytes
|
|
|
|
3: i64 hitCount
|
|
|
|
4: i64 missCount
|
|
|
|
5: i64 evictionCount
|
|
|
|
6: i64 dropCount
|
|
|
|
}
|
|
|
|
|
2017-08-25 22:41:41 +03:00
|
|
|
/**
|
|
|
|
* Struct to store fb303 counters from ServiceData.getCounters() and inode
|
|
|
|
* information of all the mount points.
|
|
|
|
*/
|
|
|
|
struct InternalStats {
|
|
|
|
1: i64 periodicUnloadCount
|
2017-12-18 22:39:47 +03:00
|
|
|
/**
|
|
|
|
* counters is the list of fb303 counters, key is the counter name, value is the
|
|
|
|
* counter value.
|
|
|
|
*/
|
2017-08-25 22:41:41 +03:00
|
|
|
2: map<string, i64> counters
|
2017-12-18 22:39:47 +03:00
|
|
|
/**
|
|
|
|
* mountPointInfo is a map whose key is the path of the mount point and value
|
|
|
|
* is the details like number of loaded inodes,unloaded inodes in that mount
|
|
|
|
* and number of materialized inodes in that mountpoint.
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
3: map<PathString, MountInodeInfo> mountPointInfo
|
2017-12-18 22:39:47 +03:00
|
|
|
/**
|
|
|
|
* Linux-only: the contents of /proc/self/smaps, to be parsed by the caller.
|
|
|
|
*/
|
|
|
|
4: binary smaps
|
2018-06-22 01:46:12 +03:00
|
|
|
/**
|
|
|
|
* Linux-only: privateBytes populated from contents of /proc/self/smaps.
|
|
|
|
* Populated with current value (the fb303 counters value is an average).
|
|
|
|
*/
|
|
|
|
5: i64 privateBytes
|
|
|
|
/**
|
|
|
|
* Linux-only: vmRSS bytes is populated from contents of /proc/self/stats.
|
|
|
|
* Populated with current value (the fb303 counters value is an average).
|
|
|
|
*/
|
|
|
|
6: i64 vmRSSBytes
|
2018-12-07 06:25:38 +03:00
|
|
|
/**
|
|
|
|
* Statistics about the in-memory blob cache.
|
|
|
|
*/
|
|
|
|
7: CacheStats blobCacheStats
|
2019-06-07 23:33:49 +03:00
|
|
|
/**
|
|
|
|
* mountPointJournalInfo is a map whose key is the path of the mount point
|
|
|
|
* and whose value is information about the journal on that mount
|
|
|
|
*/
|
|
|
|
8: map<PathString, JournalInfo> mountPointJournalInfo
|
2017-08-25 22:41:41 +03:00
|
|
|
}
|
|
|
|
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
struct ManifestEntry {
|
|
|
|
/* mode_t */
|
|
|
|
1: i32 mode
|
|
|
|
}
|
|
|
|
|
2018-03-20 20:18:29 +03:00
|
|
|
struct FuseCall {
|
|
|
|
1: i32 len
|
|
|
|
2: i32 opcode
|
|
|
|
3: i64 unique
|
|
|
|
4: i64 nodeid
|
|
|
|
5: i32 uid
|
|
|
|
6: i32 gid
|
2018-09-10 23:42:12 +03:00
|
|
|
7: pid_t pid
|
2018-03-20 20:18:29 +03:00
|
|
|
}
|
|
|
|
|
2019-06-11 22:59:03 +03:00
|
|
|
struct GetConfigParams {
|
|
|
|
// Whether to reload the config from disk to make sure it is up-to-date
|
|
|
|
1: eden_config.ConfigReloadBehavior reload =
|
|
|
|
eden_config.ConfigReloadBehavior.AutoReload
|
|
|
|
}
|
|
|
|
|
2020-04-28 21:07:00 +03:00
|
|
|
/**
|
|
|
|
* A representation of the system-dependent dirent::d_type field.
|
2019-02-19 22:23:30 +03:00
|
|
|
* The bits and their interpretation is system dependent.
|
|
|
|
* This value is u8 on all systems that implement it. We
|
|
|
|
* use i16 to pass this through thrift, which doesn't have unsigned
|
2020-04-28 21:07:00 +03:00
|
|
|
* numbers
|
|
|
|
*/
|
|
|
|
typedef i16 OsDtype
|
|
|
|
|
2020-04-28 23:19:10 +03:00
|
|
|
/**
|
2020-04-28 21:07:00 +03:00
|
|
|
* These numbers match up with Linux and macOS.
|
|
|
|
* Windows doesn't have dtype_t, but a subset of these map to and from
|
|
|
|
* the GetFileType and dwFileAttributes equivalents.
|
|
|
|
*
|
|
|
|
* Dtype and OsDtype can be cast between each other on all platforms.
|
2020-04-28 23:19:10 +03:00
|
|
|
*/
|
2020-04-28 21:07:00 +03:00
|
|
|
enum Dtype {
|
|
|
|
UNKNOWN = 0
|
|
|
|
FIFO = 1 // DT_FIFO
|
|
|
|
CHAR = 2 // DT_CHR
|
|
|
|
DIR = 4 // DT_DIR
|
|
|
|
BLOCK = 6 // DT_BLK
|
|
|
|
REGULAR = 8 // DT_REG
|
|
|
|
LINK = 10 // DT_LNK
|
|
|
|
SOCKET = 12 // DT_SOCK
|
|
|
|
WHITEOUT = 14 // DT_WHT
|
|
|
|
}
|
2019-02-19 22:23:30 +03:00
|
|
|
|
Thrift API change: deprecate glob() in favor of globFiles().
Summary:
We need to introduce a new `includeDotfiles` option to `glob()`. [As we have
done for all of our Thrift API, to date], rather than define `glob()` so that it
takes a single struct, we specified the parameters individually, so we can no
longer add new params to `glob()`.
In particular, we need to support `includeDotfiles` because we often configure
Buck to use Watchman to implement `glob()` in `BUCK` files, and when Watchman is
used in Eden, it leverages Eden's Thrift API to implement `glob()`. Because
Buck's `glob()` has an `include_dotfiles` option, we must be able to honor it
and pass it all the way through to Eden's `glob()` implementation.
Rather than name the new API `glob2()`, I'm electing to go with `globFiles()`.
(Perhaps once we eliminate all known users of `glob()` in the wild, which
requires turning over the current version of Watchman we have deployed, we can
redefine `glob()` in `eden.thrift` to be the same as `globFiles()` and then
update everyone to use `glob()` again so it has the more intuitive name.)
Reviewed By: wez
Differential Revision: D7748870
fbshipit-source-id: 92438f9c41e4fbdbd6cdccca5fce0e41cc3e9b07
2018-05-03 00:41:34 +03:00
|
|
|
/** Params for globFiles(). */
|
|
|
|
struct GlobParams {
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
Thrift API change: deprecate glob() in favor of globFiles().
Summary:
We need to introduce a new `includeDotfiles` option to `glob()`. [As we have
done for all of our Thrift API, to date], rather than define `glob()` so that it
takes a single struct, we specified the parameters individually, so we can no
longer add new params to `glob()`.
In particular, we need to support `includeDotfiles` because we often configure
Buck to use Watchman to implement `glob()` in `BUCK` files, and when Watchman is
used in Eden, it leverages Eden's Thrift API to implement `glob()`. Because
Buck's `glob()` has an `include_dotfiles` option, we must be able to honor it
and pass it all the way through to Eden's `glob()` implementation.
Rather than name the new API `glob2()`, I'm electing to go with `globFiles()`.
(Perhaps once we eliminate all known users of `glob()` in the wild, which
requires turning over the current version of Watchman we have deployed, we can
redefine `glob()` in `eden.thrift` to be the same as `globFiles()` and then
update everyone to use `glob()` again so it has the more intuitive name.)
Reviewed By: wez
Differential Revision: D7748870
fbshipit-source-id: 92438f9c41e4fbdbd6cdccca5fce0e41cc3e9b07
2018-05-03 00:41:34 +03:00
|
|
|
2: list<string> globs,
|
|
|
|
3: bool includeDotfiles,
|
2018-05-25 23:47:49 +03:00
|
|
|
// if true, prefetch matching blobs
|
2018-05-25 23:47:46 +03:00
|
|
|
4: bool prefetchFiles,
|
2018-05-25 23:47:49 +03:00
|
|
|
// if true, don't populate matchingFiles in the Glob
|
|
|
|
// results. This only really makes sense with prefetchFiles.
|
|
|
|
5: bool suppressFileList,
|
2019-02-19 22:23:30 +03:00
|
|
|
6: bool wantDtype,
|
Thrift API change: deprecate glob() in favor of globFiles().
Summary:
We need to introduce a new `includeDotfiles` option to `glob()`. [As we have
done for all of our Thrift API, to date], rather than define `glob()` so that it
takes a single struct, we specified the parameters individually, so we can no
longer add new params to `glob()`.
In particular, we need to support `includeDotfiles` because we often configure
Buck to use Watchman to implement `glob()` in `BUCK` files, and when Watchman is
used in Eden, it leverages Eden's Thrift API to implement `glob()`. Because
Buck's `glob()` has an `include_dotfiles` option, we must be able to honor it
and pass it all the way through to Eden's `glob()` implementation.
Rather than name the new API `glob2()`, I'm electing to go with `globFiles()`.
(Perhaps once we eliminate all known users of `glob()` in the wild, which
requires turning over the current version of Watchman we have deployed, we can
redefine `glob()` in `eden.thrift` to be the same as `globFiles()` and then
update everyone to use `glob()` again so it has the more intuitive name.)
Reviewed By: wez
Differential Revision: D7748870
fbshipit-source-id: 92438f9c41e4fbdbd6cdccca5fce0e41cc3e9b07
2018-05-03 00:41:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
struct Glob {
|
|
|
|
/**
|
|
|
|
* This list cannot contain duplicate values and is not guaranteed to be
|
|
|
|
* sorted.
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
1: list<PathString> matchingFiles,
|
2020-04-28 21:07:00 +03:00
|
|
|
2: list<OsDtype> dtypes,
|
Thrift API change: deprecate glob() in favor of globFiles().
Summary:
We need to introduce a new `includeDotfiles` option to `glob()`. [As we have
done for all of our Thrift API, to date], rather than define `glob()` so that it
takes a single struct, we specified the parameters individually, so we can no
longer add new params to `glob()`.
In particular, we need to support `includeDotfiles` because we often configure
Buck to use Watchman to implement `glob()` in `BUCK` files, and when Watchman is
used in Eden, it leverages Eden's Thrift API to implement `glob()`. Because
Buck's `glob()` has an `include_dotfiles` option, we must be able to honor it
and pass it all the way through to Eden's `glob()` implementation.
Rather than name the new API `glob2()`, I'm electing to go with `globFiles()`.
(Perhaps once we eliminate all known users of `glob()` in the wild, which
requires turning over the current version of Watchman we have deployed, we can
redefine `glob()` in `eden.thrift` to be the same as `globFiles()` and then
update everyone to use `glob()` again so it has the more intuitive name.)
Reviewed By: wez
Differential Revision: D7748870
fbshipit-source-id: 92438f9c41e4fbdbd6cdccca5fce0e41cc3e9b07
2018-05-03 00:41:34 +03:00
|
|
|
}
|
|
|
|
|
2019-07-26 20:03:50 +03:00
|
|
|
struct AccessCounts {
|
2019-08-01 23:34:28 +03:00
|
|
|
1: i64 fuseTotal
|
|
|
|
2: i64 fuseReads
|
|
|
|
3: i64 fuseWrites
|
|
|
|
4: i64 fuseBackingStoreImports
|
2019-08-02 19:40:15 +03:00
|
|
|
5: i64 fuseDurationNs
|
2018-09-10 23:42:12 +03:00
|
|
|
}
|
|
|
|
|
2019-08-01 23:34:28 +03:00
|
|
|
struct MountAccesses {
|
|
|
|
1: map<pid_t, AccessCounts> accessCountsByPid
|
2020-06-25 01:35:07 +03:00
|
|
|
2: map<pid_t, i64> fetchCountsByPid
|
2018-09-10 23:42:12 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
struct GetAccessCountsResult {
|
2019-08-01 23:34:28 +03:00
|
|
|
1: map<pid_t, binary> cmdsByPid
|
|
|
|
2: map<PathString, MountAccesses> accessesByMount
|
2018-09-10 23:42:12 +03:00
|
|
|
// TODO: Count the number of thrift requests
|
|
|
|
// 3: map<pid_t, AccessCount> thriftAccesses
|
|
|
|
}
|
|
|
|
|
2018-11-01 18:06:07 +03:00
|
|
|
enum TracePointEvent {
|
|
|
|
// Start of a new block
|
|
|
|
START = 0;
|
|
|
|
// End of a block
|
|
|
|
STOP = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct TracePoint {
|
|
|
|
// Holds nanoseconds since the epoch
|
|
|
|
1: i64 timestamp,
|
|
|
|
// Opaque identifier for the entire trace - used to associate this
|
|
|
|
// tracepoint with other tracepoints across an entire request
|
|
|
|
2: i64 traceId,
|
|
|
|
// Opaque identifier for this "block" where a block is some logical
|
|
|
|
// piece of work with a well-defined start and stop point
|
|
|
|
3: i64 blockId,
|
|
|
|
// Opaque identifer for the parent block from which the current
|
|
|
|
// block was constructed - used to create causal relationships
|
|
|
|
// between blocks
|
|
|
|
4: i64 parentBlockId,
|
|
|
|
// The name of the block, only set on the tracepoint starting the
|
|
|
|
// block, must point to a statically allocated cstring
|
|
|
|
5: string name = "",
|
|
|
|
// What event this trace point represents
|
|
|
|
6: TracePointEvent event,
|
|
|
|
}
|
|
|
|
|
2019-02-16 06:00:36 +03:00
|
|
|
struct FaultDefinition {
|
|
|
|
1: string keyClass
|
|
|
|
2: string keyValueRegex
|
|
|
|
// If count is non-zero this fault will automatically expire after it has
|
|
|
|
// been hit count times.
|
|
|
|
3: i64 count
|
|
|
|
// If block is true the fault will block until explicitly unblocked later.
|
|
|
|
// delayMilliseconds and errorMessage will be ignored if block is true
|
|
|
|
4: bool block
|
|
|
|
5: i64 delayMilliseconds
|
|
|
|
6: optional string errorType
|
|
|
|
7: optional string errorMessage
|
|
|
|
}
|
|
|
|
|
|
|
|
struct RemoveFaultArg {
|
|
|
|
1: string keyClass
|
|
|
|
2: string keyValueRegex
|
|
|
|
}
|
|
|
|
|
|
|
|
struct UnblockFaultArg {
|
|
|
|
1: optional string keyClass
|
|
|
|
2: optional string keyValueRegex
|
|
|
|
3: optional string errorType
|
|
|
|
4: optional string errorMessage
|
|
|
|
}
|
|
|
|
|
2019-10-29 19:54:26 +03:00
|
|
|
struct GetScmStatusResult {
|
|
|
|
1: ScmStatus status
|
|
|
|
// The version of the EdenFS daemon.
|
|
|
|
// This is returned since we usually want status calls to be able to check
|
|
|
|
// the current EdenFS version and warn the user if EdenFS is running an old
|
|
|
|
// or known-bad version.
|
|
|
|
2: string version
|
|
|
|
}
|
|
|
|
|
|
|
|
struct GetScmStatusParams {
|
|
|
|
/**
|
|
|
|
* The Eden checkout to query
|
|
|
|
*/
|
|
|
|
1: PathString mountPoint
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The commit ID of the current working directory parent commit.
|
|
|
|
*
|
|
|
|
* An error will be returned if this is not actually the current parent
|
|
|
|
* commit. This behavior exists to support callers that do not perform their
|
|
|
|
* own external synchronization around access to the current parent commit,
|
|
|
|
* like Mercurial.
|
|
|
|
*/
|
|
|
|
2: BinaryHash commit
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether ignored files should be reported in the results.
|
|
|
|
*
|
|
|
|
* Some special source-control related files (e.g., inside the .hg or .git
|
|
|
|
* directory) will never be reported even when listIgnored is true.
|
|
|
|
*/
|
|
|
|
3: bool listIgnored = false
|
|
|
|
}
|
|
|
|
|
2019-07-25 07:04:08 +03:00
|
|
|
service EdenService extends fb303_core.BaseService {
|
2016-05-12 23:43:17 +03:00
|
|
|
list<MountInfo> listMounts() throws (1: EdenError ex)
|
2019-01-02 23:55:02 +03:00
|
|
|
void mount(1: MountArgument info) throws (1: EdenError ex)
|
2018-08-11 11:34:44 +03:00
|
|
|
void unmount(1: PathString mountPoint) throws (1: EdenError ex)
|
2016-05-12 23:43:17 +03:00
|
|
|
|
2017-02-16 07:31:48 +03:00
|
|
|
/**
|
Change how the UNTRACKED_ADDED conflict and merges are handled.
Summary:
Previously, we used the Mercurial code `g` when faced with an `UNTRACKED_ADDED`
file conflict, but that was allowing merges to silently succeed that should not
have. This revision changes our logic to use the code `m` for merge, which
unearthed that we were not honoring the user's `update.check` setting properly.
Because we use `update.check=noconflict` internally at Facebook, we changed the
Eden integration tests to default to verifying Hg running with this setting. To
support it properly, we had to port this code from `update.py` in Mercurial to
our own `_determine_actions_for_conflicts()` function:
```
if updatecheck == 'noconflict':
for f, (m, args, msg) in actionbyfile.iteritems():
if m not in ('g', 'k', 'e', 'r', 'pr'):
msg = _("conflicting changes")
hint = _("commit or update --clean to discard changes")
raise error.Abort(msg, hint=hint)
```
However, this introduced an interesting issue where the `checkOutRevision()`
Thrift call from Hg would update the `SNAPSHOT` file on the server, but
`.hg/dirstate` would not get updated with the new parents until the update
completed on the client. With the new call to `raise error.Abort` on the client,
we could get in a state where the `SNAPSHOT` file had the hash of the commit
assuming the update succeeded, but `.hg/dirstate` reflected the reality where it
failed.
To that end, we changed `checkOutRevision()` to take a new parameter,
`checkoutMode`, which can take on one of three values: `NORMAL`, `DRY_RUN`, and
`FORCE`. Now if the user tries to do an ordinary `hg update` with
`update.check=noconflict`, we first do a `DRY_RUN` and examine the potential
conflicts. Only if the conflicts should not block the update do we proceed with
a call to `checkOutRevision()` in `NORMAL` mode.
To make this work, we had to make a number of changes to `CheckoutAction`,
`CheckoutContext`, `EdenMount`, and `TreeInode` to keep track of the
`checkoutMode` and ensure that no changes are made to the working copy when a
`DRY_RUN` is in effect.
One minor issue (for which there is a `TODO`) is that a `DRY_RUN` will not
report any `DIRECTORY_NOT_EMPTY` conflicts that may exist. As `TreeInode` is
implemented today, it is a bit messy to report this type of conflict without
modifying the working copy along the way.
Finally, any `UNTRACKED_ADDED` conflict should cause an update to
abort to match the behavior in stock Mercurial if the user has the following
config setting:
```
[commands]
update.check = noconflict
```
Though the original name for this setting was:
```
[experimental]
updatecheck = noconflict
```
Although I am on Mercurial 4.4.1, the `update.check` setting does not seem to
take effect when I run the integration tests, but the `updatecheck` setting
does, so for now, I set both in `hg_extension_test_base.py` with a `TODO` to
remove `updatecheck` once I can get `update.check` to do its job.
Reviewed By: simpkins
Differential Revision: D6366007
fbshipit-source-id: bb3ecb1270e77d59d7d9e7baa36ada61971bbc49
2017-11-30 08:38:12 +03:00
|
|
|
* Potentially check out the specified snapshot, reporting conflicts (and
|
|
|
|
* possibly errors), as appropriate.
|
2017-02-16 07:31:48 +03:00
|
|
|
*
|
Change how the UNTRACKED_ADDED conflict and merges are handled.
Summary:
Previously, we used the Mercurial code `g` when faced with an `UNTRACKED_ADDED`
file conflict, but that was allowing merges to silently succeed that should not
have. This revision changes our logic to use the code `m` for merge, which
unearthed that we were not honoring the user's `update.check` setting properly.
Because we use `update.check=noconflict` internally at Facebook, we changed the
Eden integration tests to default to verifying Hg running with this setting. To
support it properly, we had to port this code from `update.py` in Mercurial to
our own `_determine_actions_for_conflicts()` function:
```
if updatecheck == 'noconflict':
for f, (m, args, msg) in actionbyfile.iteritems():
if m not in ('g', 'k', 'e', 'r', 'pr'):
msg = _("conflicting changes")
hint = _("commit or update --clean to discard changes")
raise error.Abort(msg, hint=hint)
```
However, this introduced an interesting issue where the `checkOutRevision()`
Thrift call from Hg would update the `SNAPSHOT` file on the server, but
`.hg/dirstate` would not get updated with the new parents until the update
completed on the client. With the new call to `raise error.Abort` on the client,
we could get in a state where the `SNAPSHOT` file had the hash of the commit
assuming the update succeeded, but `.hg/dirstate` reflected the reality where it
failed.
To that end, we changed `checkOutRevision()` to take a new parameter,
`checkoutMode`, which can take on one of three values: `NORMAL`, `DRY_RUN`, and
`FORCE`. Now if the user tries to do an ordinary `hg update` with
`update.check=noconflict`, we first do a `DRY_RUN` and examine the potential
conflicts. Only if the conflicts should not block the update do we proceed with
a call to `checkOutRevision()` in `NORMAL` mode.
To make this work, we had to make a number of changes to `CheckoutAction`,
`CheckoutContext`, `EdenMount`, and `TreeInode` to keep track of the
`checkoutMode` and ensure that no changes are made to the working copy when a
`DRY_RUN` is in effect.
One minor issue (for which there is a `TODO`) is that a `DRY_RUN` will not
report any `DIRECTORY_NOT_EMPTY` conflicts that may exist. As `TreeInode` is
implemented today, it is a bit messy to report this type of conflict without
modifying the working copy along the way.
Finally, any `UNTRACKED_ADDED` conflict should cause an update to
abort to match the behavior in stock Mercurial if the user has the following
config setting:
```
[commands]
update.check = noconflict
```
Though the original name for this setting was:
```
[experimental]
updatecheck = noconflict
```
Although I am on Mercurial 4.4.1, the `update.check` setting does not seem to
take effect when I run the integration tests, but the `updatecheck` setting
does, so for now, I set both in `hg_extension_test_base.py` with a `TODO` to
remove `updatecheck` once I can get `update.check` to do its job.
Reviewed By: simpkins
Differential Revision: D6366007
fbshipit-source-id: bb3ecb1270e77d59d7d9e7baa36ada61971bbc49
2017-11-30 08:38:12 +03:00
|
|
|
* If the checkoutMode is FORCE, the working directory will be forcibly
|
|
|
|
* updated to the contents of the new snapshot, even if there were conflicts.
|
|
|
|
* Conflicts will still be reported in the return value, but the files will be
|
|
|
|
* updated to their new state.
|
2017-02-16 07:31:48 +03:00
|
|
|
*
|
Change how the UNTRACKED_ADDED conflict and merges are handled.
Summary:
Previously, we used the Mercurial code `g` when faced with an `UNTRACKED_ADDED`
file conflict, but that was allowing merges to silently succeed that should not
have. This revision changes our logic to use the code `m` for merge, which
unearthed that we were not honoring the user's `update.check` setting properly.
Because we use `update.check=noconflict` internally at Facebook, we changed the
Eden integration tests to default to verifying Hg running with this setting. To
support it properly, we had to port this code from `update.py` in Mercurial to
our own `_determine_actions_for_conflicts()` function:
```
if updatecheck == 'noconflict':
for f, (m, args, msg) in actionbyfile.iteritems():
if m not in ('g', 'k', 'e', 'r', 'pr'):
msg = _("conflicting changes")
hint = _("commit or update --clean to discard changes")
raise error.Abort(msg, hint=hint)
```
However, this introduced an interesting issue where the `checkOutRevision()`
Thrift call from Hg would update the `SNAPSHOT` file on the server, but
`.hg/dirstate` would not get updated with the new parents until the update
completed on the client. With the new call to `raise error.Abort` on the client,
we could get in a state where the `SNAPSHOT` file had the hash of the commit
assuming the update succeeded, but `.hg/dirstate` reflected the reality where it
failed.
To that end, we changed `checkOutRevision()` to take a new parameter,
`checkoutMode`, which can take on one of three values: `NORMAL`, `DRY_RUN`, and
`FORCE`. Now if the user tries to do an ordinary `hg update` with
`update.check=noconflict`, we first do a `DRY_RUN` and examine the potential
conflicts. Only if the conflicts should not block the update do we proceed with
a call to `checkOutRevision()` in `NORMAL` mode.
To make this work, we had to make a number of changes to `CheckoutAction`,
`CheckoutContext`, `EdenMount`, and `TreeInode` to keep track of the
`checkoutMode` and ensure that no changes are made to the working copy when a
`DRY_RUN` is in effect.
One minor issue (for which there is a `TODO`) is that a `DRY_RUN` will not
report any `DIRECTORY_NOT_EMPTY` conflicts that may exist. As `TreeInode` is
implemented today, it is a bit messy to report this type of conflict without
modifying the working copy along the way.
Finally, any `UNTRACKED_ADDED` conflict should cause an update to
abort to match the behavior in stock Mercurial if the user has the following
config setting:
```
[commands]
update.check = noconflict
```
Though the original name for this setting was:
```
[experimental]
updatecheck = noconflict
```
Although I am on Mercurial 4.4.1, the `update.check` setting does not seem to
take effect when I run the integration tests, but the `updatecheck` setting
does, so for now, I set both in `hg_extension_test_base.py` with a `TODO` to
remove `updatecheck` once I can get `update.check` to do its job.
Reviewed By: simpkins
Differential Revision: D6366007
fbshipit-source-id: bb3ecb1270e77d59d7d9e7baa36ada61971bbc49
2017-11-30 08:38:12 +03:00
|
|
|
* If the checkoutMode is NORMAL, files with conflicts will be left
|
|
|
|
* unmodified. Files that are untracked in both the source and destination
|
|
|
|
* snapshots are always left unchanged, even if force is true.
|
2017-02-16 07:31:48 +03:00
|
|
|
*
|
Change how the UNTRACKED_ADDED conflict and merges are handled.
Summary:
Previously, we used the Mercurial code `g` when faced with an `UNTRACKED_ADDED`
file conflict, but that was allowing merges to silently succeed that should not
have. This revision changes our logic to use the code `m` for merge, which
unearthed that we were not honoring the user's `update.check` setting properly.
Because we use `update.check=noconflict` internally at Facebook, we changed the
Eden integration tests to default to verifying Hg running with this setting. To
support it properly, we had to port this code from `update.py` in Mercurial to
our own `_determine_actions_for_conflicts()` function:
```
if updatecheck == 'noconflict':
for f, (m, args, msg) in actionbyfile.iteritems():
if m not in ('g', 'k', 'e', 'r', 'pr'):
msg = _("conflicting changes")
hint = _("commit or update --clean to discard changes")
raise error.Abort(msg, hint=hint)
```
However, this introduced an interesting issue where the `checkOutRevision()`
Thrift call from Hg would update the `SNAPSHOT` file on the server, but
`.hg/dirstate` would not get updated with the new parents until the update
completed on the client. With the new call to `raise error.Abort` on the client,
we could get in a state where the `SNAPSHOT` file had the hash of the commit
assuming the update succeeded, but `.hg/dirstate` reflected the reality where it
failed.
To that end, we changed `checkOutRevision()` to take a new parameter,
`checkoutMode`, which can take on one of three values: `NORMAL`, `DRY_RUN`, and
`FORCE`. Now if the user tries to do an ordinary `hg update` with
`update.check=noconflict`, we first do a `DRY_RUN` and examine the potential
conflicts. Only if the conflicts should not block the update do we proceed with
a call to `checkOutRevision()` in `NORMAL` mode.
To make this work, we had to make a number of changes to `CheckoutAction`,
`CheckoutContext`, `EdenMount`, and `TreeInode` to keep track of the
`checkoutMode` and ensure that no changes are made to the working copy when a
`DRY_RUN` is in effect.
One minor issue (for which there is a `TODO`) is that a `DRY_RUN` will not
report any `DIRECTORY_NOT_EMPTY` conflicts that may exist. As `TreeInode` is
implemented today, it is a bit messy to report this type of conflict without
modifying the working copy along the way.
Finally, any `UNTRACKED_ADDED` conflict should cause an update to
abort to match the behavior in stock Mercurial if the user has the following
config setting:
```
[commands]
update.check = noconflict
```
Though the original name for this setting was:
```
[experimental]
updatecheck = noconflict
```
Although I am on Mercurial 4.4.1, the `update.check` setting does not seem to
take effect when I run the integration tests, but the `updatecheck` setting
does, so for now, I set both in `hg_extension_test_base.py` with a `TODO` to
remove `updatecheck` once I can get `update.check` to do its job.
Reviewed By: simpkins
Differential Revision: D6366007
fbshipit-source-id: bb3ecb1270e77d59d7d9e7baa36ada61971bbc49
2017-11-30 08:38:12 +03:00
|
|
|
* If the checkoutMode is DRY_RUN, then no files are modified in the working
|
|
|
|
* copy and the current snapshot does not change. However, potential conflicts
|
|
|
|
* are still reported in the return value.
|
2017-02-16 07:31:48 +03:00
|
|
|
*
|
Change how the UNTRACKED_ADDED conflict and merges are handled.
Summary:
Previously, we used the Mercurial code `g` when faced with an `UNTRACKED_ADDED`
file conflict, but that was allowing merges to silently succeed that should not
have. This revision changes our logic to use the code `m` for merge, which
unearthed that we were not honoring the user's `update.check` setting properly.
Because we use `update.check=noconflict` internally at Facebook, we changed the
Eden integration tests to default to verifying Hg running with this setting. To
support it properly, we had to port this code from `update.py` in Mercurial to
our own `_determine_actions_for_conflicts()` function:
```
if updatecheck == 'noconflict':
for f, (m, args, msg) in actionbyfile.iteritems():
if m not in ('g', 'k', 'e', 'r', 'pr'):
msg = _("conflicting changes")
hint = _("commit or update --clean to discard changes")
raise error.Abort(msg, hint=hint)
```
However, this introduced an interesting issue where the `checkOutRevision()`
Thrift call from Hg would update the `SNAPSHOT` file on the server, but
`.hg/dirstate` would not get updated with the new parents until the update
completed on the client. With the new call to `raise error.Abort` on the client,
we could get in a state where the `SNAPSHOT` file had the hash of the commit
assuming the update succeeded, but `.hg/dirstate` reflected the reality where it
failed.
To that end, we changed `checkOutRevision()` to take a new parameter,
`checkoutMode`, which can take on one of three values: `NORMAL`, `DRY_RUN`, and
`FORCE`. Now if the user tries to do an ordinary `hg update` with
`update.check=noconflict`, we first do a `DRY_RUN` and examine the potential
conflicts. Only if the conflicts should not block the update do we proceed with
a call to `checkOutRevision()` in `NORMAL` mode.
To make this work, we had to make a number of changes to `CheckoutAction`,
`CheckoutContext`, `EdenMount`, and `TreeInode` to keep track of the
`checkoutMode` and ensure that no changes are made to the working copy when a
`DRY_RUN` is in effect.
One minor issue (for which there is a `TODO`) is that a `DRY_RUN` will not
report any `DIRECTORY_NOT_EMPTY` conflicts that may exist. As `TreeInode` is
implemented today, it is a bit messy to report this type of conflict without
modifying the working copy along the way.
Finally, any `UNTRACKED_ADDED` conflict should cause an update to
abort to match the behavior in stock Mercurial if the user has the following
config setting:
```
[commands]
update.check = noconflict
```
Though the original name for this setting was:
```
[experimental]
updatecheck = noconflict
```
Although I am on Mercurial 4.4.1, the `update.check` setting does not seem to
take effect when I run the integration tests, but the `updatecheck` setting
does, so for now, I set both in `hg_extension_test_base.py` with a `TODO` to
remove `updatecheck` once I can get `update.check` to do its job.
Reviewed By: simpkins
Differential Revision: D6366007
fbshipit-source-id: bb3ecb1270e77d59d7d9e7baa36ada61971bbc49
2017-11-30 08:38:12 +03:00
|
|
|
* On successful return from this function (unless it is a DRY_RUN), the mount
|
|
|
|
* point will point to the new snapshot, even if some paths had conflicts or
|
|
|
|
* errors. The caller is responsible for taking appropriate action to update
|
|
|
|
* these paths as desired after checkOutRevision() returns.
|
2017-02-16 07:31:48 +03:00
|
|
|
*/
|
|
|
|
list<CheckoutConflict> checkOutRevision(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2017-04-07 03:44:05 +03:00
|
|
|
2: BinaryHash snapshotHash,
|
Change how the UNTRACKED_ADDED conflict and merges are handled.
Summary:
Previously, we used the Mercurial code `g` when faced with an `UNTRACKED_ADDED`
file conflict, but that was allowing merges to silently succeed that should not
have. This revision changes our logic to use the code `m` for merge, which
unearthed that we were not honoring the user's `update.check` setting properly.
Because we use `update.check=noconflict` internally at Facebook, we changed the
Eden integration tests to default to verifying Hg running with this setting. To
support it properly, we had to port this code from `update.py` in Mercurial to
our own `_determine_actions_for_conflicts()` function:
```
if updatecheck == 'noconflict':
for f, (m, args, msg) in actionbyfile.iteritems():
if m not in ('g', 'k', 'e', 'r', 'pr'):
msg = _("conflicting changes")
hint = _("commit or update --clean to discard changes")
raise error.Abort(msg, hint=hint)
```
However, this introduced an interesting issue where the `checkOutRevision()`
Thrift call from Hg would update the `SNAPSHOT` file on the server, but
`.hg/dirstate` would not get updated with the new parents until the update
completed on the client. With the new call to `raise error.Abort` on the client,
we could get in a state where the `SNAPSHOT` file had the hash of the commit
assuming the update succeeded, but `.hg/dirstate` reflected the reality where it
failed.
To that end, we changed `checkOutRevision()` to take a new parameter,
`checkoutMode`, which can take on one of three values: `NORMAL`, `DRY_RUN`, and
`FORCE`. Now if the user tries to do an ordinary `hg update` with
`update.check=noconflict`, we first do a `DRY_RUN` and examine the potential
conflicts. Only if the conflicts should not block the update do we proceed with
a call to `checkOutRevision()` in `NORMAL` mode.
To make this work, we had to make a number of changes to `CheckoutAction`,
`CheckoutContext`, `EdenMount`, and `TreeInode` to keep track of the
`checkoutMode` and ensure that no changes are made to the working copy when a
`DRY_RUN` is in effect.
One minor issue (for which there is a `TODO`) is that a `DRY_RUN` will not
report any `DIRECTORY_NOT_EMPTY` conflicts that may exist. As `TreeInode` is
implemented today, it is a bit messy to report this type of conflict without
modifying the working copy along the way.
Finally, any `UNTRACKED_ADDED` conflict should cause an update to
abort to match the behavior in stock Mercurial if the user has the following
config setting:
```
[commands]
update.check = noconflict
```
Though the original name for this setting was:
```
[experimental]
updatecheck = noconflict
```
Although I am on Mercurial 4.4.1, the `update.check` setting does not seem to
take effect when I run the integration tests, but the `updatecheck` setting
does, so for now, I set both in `hg_extension_test_base.py` with a `TODO` to
remove `updatecheck` once I can get `update.check` to do its job.
Reviewed By: simpkins
Differential Revision: D6366007
fbshipit-source-id: bb3ecb1270e77d59d7d9e7baa36ada61971bbc49
2017-11-30 08:38:12 +03:00
|
|
|
3: CheckoutMode checkoutMode)
|
2017-02-16 07:31:48 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-05-28 04:16:27 +03:00
|
|
|
|
2017-04-07 03:44:06 +03:00
|
|
|
/**
|
2017-04-28 03:30:14 +03:00
|
|
|
* Reset the working directory's parent commits, without changing the working
|
2017-04-07 03:44:06 +03:00
|
|
|
* directory contents.
|
|
|
|
*
|
|
|
|
* This operation is equivalent to `git reset --soft` or `hg reset --keep`
|
|
|
|
*/
|
2017-04-28 03:30:14 +03:00
|
|
|
void resetParentCommits(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2017-04-28 03:30:14 +03:00
|
|
|
2: WorkingDirectoryParents parents)
|
2017-04-07 03:44:06 +03:00
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
2016-05-28 04:16:27 +03:00
|
|
|
/**
|
2016-08-18 17:21:36 +03:00
|
|
|
* For each path, returns an EdenError instead of the SHA-1 if any of the
|
|
|
|
* following occur:
|
2016-05-28 04:16:27 +03:00
|
|
|
* - path is the empty string.
|
|
|
|
* - path identifies a non-existent file.
|
|
|
|
* - path identifies something that is not an ordinary file (e.g., symlink
|
|
|
|
* or directory).
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
list<SHA1Result> getSHA1(1: PathString mountPoint, 2: list<PathString> paths)
|
2016-10-04 21:02:22 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-09-13 04:27:54 +03:00
|
|
|
|
2019-10-02 00:19:52 +03:00
|
|
|
/**
|
|
|
|
* Returns a list of paths relative to the mountPoint. DEPRECATED!
|
|
|
|
*/
|
|
|
|
list<PathString> getBindMounts(1: PathString mountPoint)
|
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
2019-06-26 04:39:31 +03:00
|
|
|
/**
|
|
|
|
* On systems that support bind mounts, establish a bind mount within the
|
|
|
|
* repo such that `mountPoint / repoPath` is redirected to `targetPath`.
|
|
|
|
* If `repoPath` is already a bind mount managed by eden, this function
|
|
|
|
* will throw an error.
|
|
|
|
* If `repoPath` is not a directory then it will be created similar to
|
|
|
|
* running `mkdir -p mountPoint/repoPath` and then the bind mount
|
|
|
|
* will be established.
|
|
|
|
* If `repoPath` exists and is not a directory, an error will be thrown.
|
|
|
|
* If the bind mount cannot be set up, an error will be thrown.
|
|
|
|
*/
|
|
|
|
void addBindMount(1: PathString mountPoint,
|
|
|
|
2: PathString repoPath,
|
|
|
|
3: PathString targetPath) throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Removes the bind mount specified by `repoPath` from the set of managed
|
|
|
|
* bind mounts.
|
|
|
|
* If `repoPath` is not a bind mount managed by eden, this function
|
|
|
|
* will throw an error.
|
|
|
|
* If the bind mount cannot be removed, an error will be thrown.
|
|
|
|
*/
|
|
|
|
void removeBindMount(1: PathString mountPoint, 2: PathString repoPath)
|
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
2016-09-19 22:48:12 +03:00
|
|
|
/** Returns the sequence position at the time the method is called.
|
|
|
|
* Returns the instantaneous value of the journal sequence number.
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
JournalPosition getCurrentJournalPosition(1: PathString mountPoint)
|
2016-10-04 21:02:22 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-09-19 22:48:12 +03:00
|
|
|
|
|
|
|
/** Returns the set of files (and dirs) that changed since a prior point.
|
2016-09-19 22:48:14 +03:00
|
|
|
* If fromPosition.mountGeneration is mismatched with the current
|
|
|
|
* mountGeneration, throws an EdenError with errorCode = ERANGE.
|
2019-07-23 22:06:13 +03:00
|
|
|
* If the domain required by fromPosition goes past the Journal's memory,
|
|
|
|
* throws an EdenError with errorCode = EDOM.
|
2016-09-19 22:48:12 +03:00
|
|
|
* This indicates that eden cannot compute the delta for the requested
|
|
|
|
* range. The client will need to recompute a new baseline using
|
|
|
|
* other available functions in EdenService.
|
|
|
|
*/
|
|
|
|
FileDelta getFilesChangedSince(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2016-09-19 22:48:12 +03:00
|
|
|
2: JournalPosition fromPosition)
|
2016-09-19 22:48:15 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-09-19 22:48:12 +03:00
|
|
|
|
2019-07-03 04:59:07 +03:00
|
|
|
/** Sets the memory limit on the journal such that the journal will forget
|
|
|
|
* old data to keep itself under a certain estimated memory use.
|
|
|
|
*/
|
|
|
|
void setJournalMemoryLimit(
|
|
|
|
1: PathString mountPoint,
|
|
|
|
2: i64 limit)
|
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/** Gets the memory limit on the journal
|
|
|
|
*/
|
|
|
|
i64 getJournalMemoryLimit(
|
|
|
|
1: PathString mountPoint,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
2019-07-31 08:02:05 +03:00
|
|
|
/** Forces the journal to flush, sending a truncated result to subscribers
|
|
|
|
*/
|
|
|
|
void flushJournal(
|
|
|
|
1: PathString mountPoint,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
2018-05-23 11:27:16 +03:00
|
|
|
/**
|
|
|
|
* Returns the journal entries for the specified params. Useful for auditing
|
|
|
|
* the changes that Eden has sent to Watchman. Note that the most recent
|
|
|
|
* journal entries will be at the front of the list in
|
|
|
|
* DebugGetRawJournalResponse.
|
|
|
|
*/
|
|
|
|
DebugGetRawJournalResponse debugGetRawJournal(
|
|
|
|
1: DebugGetRawJournalParams params,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
2020-04-28 07:48:44 +03:00
|
|
|
/**
|
|
|
|
* Returns the subset of information about a list of paths that can
|
|
|
|
* be determined from each's parent directory tree. For now, that
|
|
|
|
* includes whether the entry exists and its dtype.
|
|
|
|
*/
|
|
|
|
list<EntryInformationOrError> getEntryInformation(
|
|
|
|
1: PathString mountPoint,
|
|
|
|
2: list<PathString> paths)
|
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns a subset of the stat() information for a list of paths.
|
2016-09-19 22:48:12 +03:00
|
|
|
* The returned list of information corresponds to the input list of
|
|
|
|
* paths; eg; result[0] holds the information for paths[0].
|
|
|
|
* We only support returning the instantaneous information about
|
|
|
|
* these paths, as we cannot answer with historical information about
|
|
|
|
* files in the overlay.
|
|
|
|
*/
|
|
|
|
list<FileInformationOrError> getFileInformation(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
|
|
|
2: list<PathString> paths)
|
2016-10-04 21:02:22 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-09-19 22:48:12 +03:00
|
|
|
|
Thrift API change: deprecate glob() in favor of globFiles().
Summary:
We need to introduce a new `includeDotfiles` option to `glob()`. [As we have
done for all of our Thrift API, to date], rather than define `glob()` so that it
takes a single struct, we specified the parameters individually, so we can no
longer add new params to `glob()`.
In particular, we need to support `includeDotfiles` because we often configure
Buck to use Watchman to implement `glob()` in `BUCK` files, and when Watchman is
used in Eden, it leverages Eden's Thrift API to implement `glob()`. Because
Buck's `glob()` has an `include_dotfiles` option, we must be able to honor it
and pass it all the way through to Eden's `glob()` implementation.
Rather than name the new API `glob2()`, I'm electing to go with `globFiles()`.
(Perhaps once we eliminate all known users of `glob()` in the wild, which
requires turning over the current version of Watchman we have deployed, we can
redefine `glob()` in `eden.thrift` to be the same as `globFiles()` and then
update everyone to use `glob()` again so it has the more intuitive name.)
Reviewed By: wez
Differential Revision: D7748870
fbshipit-source-id: 92438f9c41e4fbdbd6cdccca5fce0e41cc3e9b07
2018-05-03 00:41:34 +03:00
|
|
|
/**
|
|
|
|
* DEPRECATED: Prefer globFiles().
|
|
|
|
* Returns a list of files that match the input globs.
|
2016-09-19 22:48:12 +03:00
|
|
|
* There are no duplicate values in the result.
|
|
|
|
*/
|
2018-08-11 11:34:44 +03:00
|
|
|
list<PathString> glob(
|
|
|
|
1: PathString mountPoint,
|
2017-01-26 23:45:50 +03:00
|
|
|
2: list<string> globs)
|
2016-10-04 21:02:22 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-11-26 23:00:16 +03:00
|
|
|
|
Thrift API change: deprecate glob() in favor of globFiles().
Summary:
We need to introduce a new `includeDotfiles` option to `glob()`. [As we have
done for all of our Thrift API, to date], rather than define `glob()` so that it
takes a single struct, we specified the parameters individually, so we can no
longer add new params to `glob()`.
In particular, we need to support `includeDotfiles` because we often configure
Buck to use Watchman to implement `glob()` in `BUCK` files, and when Watchman is
used in Eden, it leverages Eden's Thrift API to implement `glob()`. Because
Buck's `glob()` has an `include_dotfiles` option, we must be able to honor it
and pass it all the way through to Eden's `glob()` implementation.
Rather than name the new API `glob2()`, I'm electing to go with `globFiles()`.
(Perhaps once we eliminate all known users of `glob()` in the wild, which
requires turning over the current version of Watchman we have deployed, we can
redefine `glob()` in `eden.thrift` to be the same as `globFiles()` and then
update everyone to use `glob()` again so it has the more intuitive name.)
Reviewed By: wez
Differential Revision: D7748870
fbshipit-source-id: 92438f9c41e4fbdbd6cdccca5fce0e41cc3e9b07
2018-05-03 00:41:34 +03:00
|
|
|
/**
|
|
|
|
* Returns a list of files that match the GlobParams, notably,
|
|
|
|
* the list of glob patterns.
|
|
|
|
* There are no duplicate values in the result.
|
|
|
|
*/
|
|
|
|
Glob globFiles(
|
|
|
|
1: GlobParams params,
|
|
|
|
) throws (1: EdenError ex)
|
2016-11-26 23:00:16 +03:00
|
|
|
|
2018-11-07 19:56:49 +03:00
|
|
|
/**
|
|
|
|
* Chowns all files in the requested mount to the requested uid and gid
|
|
|
|
*/
|
|
|
|
void chown(1: PathString mountPoint, 2: i32 uid, 3: i32 gid)
|
|
|
|
|
2019-10-29 19:54:26 +03:00
|
|
|
/**
|
|
|
|
* Return the list of files that are different from the specified source
|
|
|
|
* control commit.
|
|
|
|
*/
|
|
|
|
GetScmStatusResult getScmStatusV2(
|
|
|
|
1: GetScmStatusParams params
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
2017-10-26 08:24:47 +03:00
|
|
|
/**
|
2018-04-06 22:41:51 +03:00
|
|
|
* Get the status of the working directory against the specified commit.
|
|
|
|
*
|
2019-10-29 19:54:26 +03:00
|
|
|
* DEPRECATED: Prefer using getScmStatusV2() in new code. Callers may still
|
|
|
|
* need to fall back to getScmStatus() if talking to an older edenfs daemon
|
|
|
|
* that does not support getScmStatusV2() yet.
|
2017-10-26 08:24:47 +03:00
|
|
|
*/
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
ScmStatus getScmStatus(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
2: bool listIgnored,
|
2018-04-06 22:41:51 +03:00
|
|
|
3: BinaryHash commit,
|
2017-10-26 08:24:47 +03:00
|
|
|
) throws (1: EdenError ex)
|
2017-11-29 06:29:14 +03:00
|
|
|
|
|
|
|
/**
|
2019-12-19 21:46:11 +03:00
|
|
|
* DEPRECATED
|
|
|
|
*
|
2017-11-29 06:29:14 +03:00
|
|
|
* Computes the status between two specified revisions.
|
|
|
|
* This does not care about the state of the working copy.
|
|
|
|
*/
|
|
|
|
ScmStatus getScmStatusBetweenRevisions(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2018-03-21 02:34:01 +03:00
|
|
|
2: BinaryHash oldHash,
|
|
|
|
3: BinaryHash newHash,
|
2017-11-29 06:29:14 +03:00
|
|
|
) throws (1: EdenError ex)
|
2017-10-26 08:24:47 +03:00
|
|
|
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
//////// SCM Commit-Related APIs ////////
|
|
|
|
|
2017-10-26 08:24:47 +03:00
|
|
|
/**
|
2020-01-21 21:04:58 +03:00
|
|
|
* DEPRECATED: Remove when Mercurial has migrated to not calling
|
|
|
|
* getManifestEntry, probably by July 2020.
|
|
|
|
*
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
* If the relative path exists in the manifest (i.e., the current commit),
|
|
|
|
* then return the corresponding ManifestEntry; otherwise, throw
|
|
|
|
* NoValueForKeyError.
|
2017-10-26 08:24:47 +03:00
|
|
|
*
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
* Note that we are still experimenting with the type of SCM information Eden
|
|
|
|
* should be responsible for reporting, so this method is subject to change,
|
|
|
|
* or may go away entirely. At a minimum, it should take a commit as a
|
|
|
|
* parameter rather than assuming the current commit.
|
2017-10-26 08:24:47 +03:00
|
|
|
*/
|
Store Hg dirstate data in Hg instead of Eden.
Summary:
This is a major change to how we manage the dirstate in Eden's Hg extension.
Previously, the dirstate information was stored under `$EDEN_CONFIG_DIR`,
which is Eden's private storage. Any time the Mercurial extension wanted to
read or write the dirstate, it had to make a Thrift request to Eden to do so on
its behalf. The upside is that Eden could answer dirstate-related questions
independently of the Python code.
This was sufficiently different than how Mercurial's default dirstate worked
that our subclass, `eden_dirstate`, had to override quite a bit of behavior.
Failing to manage the `.hg/dirstate` file in a way similar to the way Mercurial
does has exposed some "unofficial contracts" that Mercurial has. For example,
tools like Nuclide rely on changes to the `.hg/dirstate` file as a heuristic to
determine when to invalidate its internal caches for Mercurial data.
Today, Mercurial has a well-factored `dirstatemap` abstraction that is primarily
responsible for the transactions with the dirstate's data. With this split, we can
focus on putting most of our customizations in our `eden_dirstate_map` subclass
while our `eden_dirstate` class has to override fewer methods. Because the
data is managed through the `.hg/dirstate` file, transaction logic in Mercurial that
relies on renaming/copying that file will work out-of-the-box. This change
also reduces the number of Thrift calls the Mercurial extension has to make
for operations like `hg status` or `hg add`.
In this revision, we introduce our own binary format for the `.hg/dirstate` file.
The logic to read and write this file is in `eden/py/dirstate.py`. After the first
40 bytes, which are used for the parent hashes, the next four bytes are
reserved for a version number for the file format so we can manage file format
changes going forward.
Admittedly one downside of this change is that it is a breaking change.
Ideally, users should commit all of their local changes in their existing mounts,
shutdown Eden, delete the old mounts, restart Eden, and re-clone.
In the end, this change deletes a number of Mercurial-specific code and Thrift
APIs from Eden. This is a better separation of concerns that makes Eden more
SCM-agnostic. For example, this change removes `Dirstate.cpp` and
`DirstatePersistance.cpp`, replacing them with the much simpler and more
general `Differ.cpp`. The Mercurial-specific logic from `Dirstate.cpp` that turned
a diff into an `hg status` now lives in the Mercurial extension in
`EdenThriftClient.getStatus()`, which is much more appropriate.
Note that this reverts the changes that were recently introduced in D6116105:
we now need to intercept `localrepo.localrepository.dirstate` once again.
Reviewed By: simpkins
Differential Revision: D6179950
fbshipit-source-id: 5b78904909b669c9cc606e2fe1fd118ef6eaab95
2017-11-07 06:44:24 +03:00
|
|
|
ManifestEntry getManifestEntry(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint
|
|
|
|
2: PathString relativePath
|
2017-09-11 20:37:13 +03:00
|
|
|
) throws (
|
|
|
|
1: EdenError ex
|
|
|
|
2: NoValueForKeyError noValueForKeyError
|
|
|
|
)
|
2016-11-26 23:00:16 +03:00
|
|
|
|
2019-06-05 21:47:01 +03:00
|
|
|
//////// Administrative APIs ////////
|
|
|
|
|
2019-07-17 23:43:32 +03:00
|
|
|
/**
|
|
|
|
* Returns information about the running process, including pid and command
|
|
|
|
* line.
|
|
|
|
*/
|
|
|
|
DaemonInfo getDaemonInfo() throws (1: EdenError ex)
|
|
|
|
|
2019-07-25 07:04:08 +03:00
|
|
|
/**
|
|
|
|
* DEPRECATED
|
|
|
|
*
|
|
|
|
* Returns the pid of the running edenfs daemon. New code should call
|
|
|
|
* getDaemonInfo instead. This method exists for Thrift clients that
|
|
|
|
* predate getDaemonInfo, such as older versions of the CLI.
|
|
|
|
*/
|
2019-07-27 01:54:25 +03:00
|
|
|
i64 getPid() throws (1: EdenError ex)
|
2019-07-25 07:04:08 +03:00
|
|
|
|
2019-06-05 21:47:01 +03:00
|
|
|
/**
|
|
|
|
* Ask the server to shutdown and provide it some context for its logs
|
|
|
|
*/
|
|
|
|
void initiateShutdown(1: string reason) throws (1: EdenError ex)
|
|
|
|
|
2019-06-11 22:59:03 +03:00
|
|
|
/**
|
|
|
|
* Get the current configuration settings
|
|
|
|
*/
|
|
|
|
eden_config.EdenConfigData getConfig(1: GetConfigParams params)
|
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
2019-06-15 04:10:35 +03:00
|
|
|
/**
|
|
|
|
* Ask eden to reload its configuration data from disk.
|
|
|
|
*/
|
|
|
|
void reloadConfig() throws (1: EdenError ex)
|
|
|
|
|
2017-04-04 01:47:53 +03:00
|
|
|
//////// Debugging APIs ////////
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the contents of a source control Tree.
|
|
|
|
*
|
|
|
|
* This can be used to confirm if eden's LocalStore contains information
|
|
|
|
* for the tree, and that the information is correct.
|
|
|
|
*
|
|
|
|
* If localStoreOnly is true, the data is loaded directly from the
|
|
|
|
* LocalStore, and an error will be raised if it is not already present in
|
|
|
|
* the LocalStore. If localStoreOnly is false, the data may be retrieved
|
|
|
|
* from the BackingStore if it is not already present in the LocalStore.
|
|
|
|
*/
|
|
|
|
list<ScmTreeEntry> debugGetScmTree(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2017-04-04 01:47:53 +03:00
|
|
|
2: BinaryHash id,
|
|
|
|
3: bool localStoreOnly,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the contents of a source control Blob.
|
|
|
|
*
|
|
|
|
* This can be used to confirm if eden's LocalStore contains information
|
|
|
|
* for the blob, and that the information is correct.
|
|
|
|
*/
|
|
|
|
binary debugGetScmBlob(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2017-04-04 01:47:53 +03:00
|
|
|
2: BinaryHash id,
|
|
|
|
3: bool localStoreOnly,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the metadata about a source control Blob.
|
|
|
|
*
|
|
|
|
* This retrieves the metadata about a source control Blob. This returns
|
|
|
|
* the size and contents SHA1 of the blob, which eden stores separately from
|
|
|
|
* the blob itself. This can also be a useful alternative to
|
|
|
|
* debugGetScmBlob() when getting data about extremely large blobs.
|
|
|
|
*/
|
|
|
|
ScmBlobMetadata debugGetScmBlobMetadata(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2017-04-04 01:47:53 +03:00
|
|
|
2: BinaryHash id,
|
|
|
|
3: bool localStoreOnly,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get status about currently loaded inode objects.
|
|
|
|
*
|
|
|
|
* This returns details about all currently loaded inode objects under the
|
|
|
|
* given path.
|
|
|
|
*
|
|
|
|
* If the path argument is the empty string data will be returned about all
|
|
|
|
* inodes in the entire mount point. Otherwise the path argument should
|
|
|
|
* refer to a subdirectory, and data will be returned for all inodes under
|
|
|
|
* the specified subdirectory.
|
|
|
|
*
|
|
|
|
* The rename lock is not held while gathering this information, so the path
|
|
|
|
* name information returned may not always be internally consistent. If
|
|
|
|
* renames were taking place while gathering the data, some inodes may show
|
|
|
|
* up under multiple parents. It's also possible that we may miss some
|
|
|
|
* inodes during the tree walk if they were renamed from a directory that was
|
|
|
|
* not yet walked into a directory that has already been walked.
|
|
|
|
*
|
|
|
|
* This API cannot return data about inodes that have been unlinked but still
|
|
|
|
* have outstanding references.
|
|
|
|
*/
|
|
|
|
list<TreeInodeDebugInfo> debugInodeStatus(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
|
|
|
2: PathString path,
|
2017-04-04 01:47:53 +03:00
|
|
|
) throws (1: EdenError ex)
|
2017-06-17 02:08:19 +03:00
|
|
|
|
2018-03-20 20:18:29 +03:00
|
|
|
/**
|
|
|
|
* Get the list of outstanding fuse requests
|
|
|
|
*
|
|
|
|
* This will return the list of FuseCall structure containing the data from
|
|
|
|
* fuse_in_header.
|
|
|
|
*/
|
|
|
|
list<FuseCall> debugOutstandingFuseCalls(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2018-03-20 20:18:29 +03:00
|
|
|
)
|
|
|
|
|
2017-08-17 05:56:32 +03:00
|
|
|
/**
|
|
|
|
* Get the InodePathDebugInfo for the inode that corresponds to the given
|
|
|
|
* inode number. This provides the path for the inode and also indicates
|
|
|
|
* whether the inode is currently loaded or not. Requires that the Eden
|
|
|
|
* mountPoint be specified.
|
|
|
|
*/
|
|
|
|
InodePathDebugInfo debugGetInodePath(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
2017-08-17 05:56:32 +03:00
|
|
|
2: i64 inodeNumber,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
2020-07-23 21:51:40 +03:00
|
|
|
/**
|
|
|
|
* Clear pidFetchCounts_ in ObjectStore to start a new recording of process
|
|
|
|
* fetch counts.
|
|
|
|
*/
|
|
|
|
void clearFetchCounts() throws (1: EdenError ex)
|
2020-07-23 21:51:40 +03:00
|
|
|
void clearFetchCountsByMount(1: PathString mountPath) throws (1: EdenError ex)
|
2020-07-23 21:51:40 +03:00
|
|
|
|
2018-09-10 23:42:12 +03:00
|
|
|
/**
|
|
|
|
* Queries all of the live Eden mounts for the processes that accessed FUSE
|
|
|
|
* over the last `duration` seconds.
|
|
|
|
*
|
|
|
|
* Note that eden only maintains a few seconds worth of accesses.
|
|
|
|
*/
|
|
|
|
GetAccessCountsResult getAccessCounts(1: i64 duration)
|
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
2018-08-10 21:09:48 +03:00
|
|
|
/**
|
|
|
|
* Column by column, clears and compacts the LocalStore. All columns are
|
|
|
|
* compacted, but only columns that contain ephemeral data are cleared.
|
|
|
|
*
|
|
|
|
* Even though the behavior of this method is identical to
|
|
|
|
* debugClearLocalStoreCaches followed by debugCompactLocalStorage(), it is
|
|
|
|
* separate so it can clear and compact each column in order to minimize the
|
|
|
|
* risk of running out of disk space. Since RocksDB is a write-ahead logging
|
|
|
|
* database, clearing a column increases its disk usage until it's compacted.
|
|
|
|
*/
|
|
|
|
void clearAndCompactLocalStore() throws (1: EdenError ex)
|
|
|
|
|
2018-05-31 20:39:53 +03:00
|
|
|
/**
|
|
|
|
* Clears all data from the LocalStore that can be populated from the upstream
|
|
|
|
* backing store.
|
|
|
|
*/
|
|
|
|
void debugClearLocalStoreCaches() throws (1: EdenError ex)
|
|
|
|
|
2018-05-31 20:39:58 +03:00
|
|
|
/**
|
|
|
|
* Asks RocksDB to perform a compaction.
|
|
|
|
*/
|
|
|
|
void debugCompactLocalStorage() throws (1: EdenError ex)
|
|
|
|
|
2017-06-17 02:08:19 +03:00
|
|
|
/**
|
2017-08-23 05:43:29 +03:00
|
|
|
* Unloads unused Inodes from a directory inside a mountPoint whose last
|
|
|
|
* access time is older than the specified age.
|
|
|
|
*
|
|
|
|
* The age parameter is a relative time to be subtracted from the current
|
|
|
|
* (wall clock) time.
|
2017-06-17 02:08:19 +03:00
|
|
|
*/
|
2017-08-23 05:43:31 +03:00
|
|
|
i64 unloadInodeForPath(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
|
|
|
2: PathString path,
|
2017-08-23 05:43:29 +03:00
|
|
|
3: TimeSpec age,
|
2017-06-17 02:08:19 +03:00
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
2017-08-18 21:43:57 +03:00
|
|
|
/**
|
|
|
|
* Flush all thread-local stats to the main ServiceData object.
|
|
|
|
*
|
|
|
|
* Thread-local counters are normally flushed to the main ServiceData once
|
|
|
|
* a second. flushStatsNow() can be used to flush thread-local counters on
|
|
|
|
* demand, in addition to the normal once-a-second flush.
|
|
|
|
*
|
|
|
|
* This is mainly useful for unit and integration tests that want to ensure
|
|
|
|
* they see up-to-date counter information without waiting for the normal
|
|
|
|
* flush interval.
|
|
|
|
*/
|
|
|
|
void flushStatsNow() throws (1: EdenError ex)
|
2017-08-22 01:52:55 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Invalidate kernel cache for inode.
|
|
|
|
*/
|
|
|
|
void invalidateKernelInodeCache(
|
2018-08-11 11:34:44 +03:00
|
|
|
1: PathString mountPoint,
|
|
|
|
2: PathString path
|
2017-08-22 01:52:55 +03:00
|
|
|
)
|
|
|
|
throws (1: EdenError ex)
|
|
|
|
|
2017-08-25 22:41:41 +03:00
|
|
|
/**
|
|
|
|
* Gets the number of inodes unloaded by periodic job on an EdenMount.
|
|
|
|
*/
|
|
|
|
InternalStats getStatInfo() throws (1: EdenError ex)
|
2018-06-19 20:57:55 +03:00
|
|
|
|
2018-11-01 18:06:07 +03:00
|
|
|
void enableTracing()
|
|
|
|
void disableTracing()
|
|
|
|
list<TracePoint> getTracePoints()
|
|
|
|
|
2019-02-16 06:00:36 +03:00
|
|
|
/**
|
|
|
|
* Configure a new fault in Eden's fault injection framework.
|
|
|
|
*
|
|
|
|
* This throws an exception if the fault injection framework was not enabled
|
|
|
|
* when edenfs was started.
|
|
|
|
*/
|
|
|
|
void injectFault(1: FaultDefinition fault) throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Remove a fault previously defined with injectFault()
|
|
|
|
*
|
|
|
|
* Returns true if a matching fault was found and remove, and false
|
|
|
|
* if no matching fault was found.
|
|
|
|
*/
|
|
|
|
bool removeFault(1: RemoveFaultArg fault) throws (1: EdenError ex)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Unblock fault injection checks pending on a block fault.
|
|
|
|
*
|
|
|
|
* Returns the number of pending calls that were unblocked
|
|
|
|
*/
|
|
|
|
i64 unblockFault(1: UnblockFaultArg info) throws (1: EdenError ex)
|
2016-05-12 23:43:17 +03:00
|
|
|
}
|