2016-05-12 23:43:17 +03:00
|
|
|
include "common/fb303/if/fb303.thrift"
|
|
|
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
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
|
|
|
|
|
|
|
struct MountInfo {
|
|
|
|
1: string mountPoint
|
|
|
|
2: string edenClientPath
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Information that we return when querying entries
|
|
|
|
*/
|
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.
|
|
|
|
*/
|
|
|
|
struct FileDelta {
|
|
|
|
/** The fromPosition passed to getFilesChangedSince */
|
|
|
|
1: JournalPosition fromPosition
|
|
|
|
/** The current position at the time that getFilesChangedSince was called */
|
|
|
|
2: JournalPosition toPosition
|
|
|
|
/** The complete list of paths from both the snapshot and the overlay that
|
|
|
|
* changed between fromPosition and toPosition */
|
2017-08-11 22:51:51 +03:00
|
|
|
3: list<string> changedPaths
|
|
|
|
4: list<string> createdPaths
|
|
|
|
5: list<string> 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. */
|
|
|
|
6: list<string> uncleanPaths
|
2016-09-19 22:48:12 +03:00
|
|
|
}
|
|
|
|
|
2018-05-23 11:27:16 +03:00
|
|
|
struct DebugGetRawJournalParams {
|
|
|
|
1: string mountPoint
|
|
|
|
2: JournalPosition fromPosition
|
|
|
|
3: JournalPosition toPosition
|
|
|
|
}
|
|
|
|
|
|
|
|
struct DebugGetRawJournalResponse {
|
|
|
|
1: list<FileDelta> deltas
|
|
|
|
}
|
|
|
|
|
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 {
|
|
|
|
1: map<string, 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.
|
|
|
|
*/
|
|
|
|
2: map<string, 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 {
|
|
|
|
1: string path
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
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 {
|
|
|
|
1: string path
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2017-08-25 22:41:41 +03:00
|
|
|
/**
|
|
|
|
* Struct to store Information about inodes in a mount point.
|
|
|
|
*/
|
|
|
|
struct MountInodeInfo {
|
|
|
|
1: i64 loadedInodeCount
|
|
|
|
2: i64 unloadedInodeCount
|
|
|
|
3: i64 materializedInodeCount
|
2018-01-25 02:18:47 +03:00
|
|
|
4: i64 loadedFileCount
|
|
|
|
5: i64 loadedTreeCount
|
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.
|
|
|
|
*/
|
2017-08-25 22:41:41 +03:00
|
|
|
3: map<string, 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
|
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
|
|
|
|
7: i32 pid
|
|
|
|
}
|
|
|
|
|
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 {
|
|
|
|
1: string mountPoint,
|
|
|
|
2: list<string> globs,
|
|
|
|
3: bool includeDotfiles,
|
|
|
|
}
|
|
|
|
|
|
|
|
struct Glob {
|
|
|
|
/**
|
|
|
|
* This list cannot contain duplicate values and is not guaranteed to be
|
|
|
|
* sorted.
|
|
|
|
*/
|
|
|
|
1: list<string> matchingFiles,
|
|
|
|
}
|
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
service EdenService extends fb303.FacebookService {
|
|
|
|
list<MountInfo> listMounts() throws (1: EdenError ex)
|
|
|
|
void mount(1: MountInfo info) throws (1: EdenError ex)
|
|
|
|
void unmount(1: string mountPoint) throws (1: EdenError ex)
|
|
|
|
|
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(
|
|
|
|
1: string 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(
|
2017-04-07 03:44:06 +03:00
|
|
|
1: string 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).
|
|
|
|
*/
|
2016-08-18 17:21:36 +03:00
|
|
|
list<SHA1Result> getSHA1(1: string mountPoint, 2: list<string> paths)
|
2016-10-04 21:02:22 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-09-13 04:27:54 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns a list of paths relative to the mountPoint.
|
|
|
|
*/
|
|
|
|
list<string> getBindMounts(1: string mountPoint)
|
2016-10-04 21:02:22 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-09-19 22:48:09 +03:00
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
JournalPosition getCurrentJournalPosition(1: string 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.
|
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(
|
|
|
|
1: string mountPoint,
|
|
|
|
2: JournalPosition fromPosition)
|
2016-09-19 22:48:15 +03:00
|
|
|
throws (1: EdenError ex)
|
2016-09-19 22:48:12 +03:00
|
|
|
|
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)
|
|
|
|
|
2016-09-19 22:48:12 +03:00
|
|
|
/** Returns a subset of the stat() information for a list of paths.
|
|
|
|
* 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(
|
|
|
|
1: string mountPoint,
|
|
|
|
2: list<string> 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.
|
|
|
|
*/
|
|
|
|
list<string> glob(
|
|
|
|
1: string 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
|
|
|
|
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.
|
|
|
|
*
|
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
|
|
|
* This may exclude special files according to the rules of the underlying
|
|
|
|
* SCM system, such as the .git folder in Git and the .hg folder in Mercurial.
|
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(
|
2017-10-26 08:24:47 +03:00
|
|
|
1: string 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
|
|
|
|
|
|
|
/**
|
|
|
|
* Computes the status between two specified revisions.
|
|
|
|
* This does not care about the state of the working copy.
|
|
|
|
*/
|
|
|
|
ScmStatus getScmStatusBetweenRevisions(
|
|
|
|
1: string 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
|
|
|
/**
|
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(
|
|
|
|
1: string mountPoint
|
|
|
|
2: string relativePath
|
2017-09-11 20:37:13 +03:00
|
|
|
) throws (
|
|
|
|
1: EdenError ex
|
|
|
|
2: NoValueForKeyError noValueForKeyError
|
|
|
|
)
|
2016-11-26 23:00:16 +03:00
|
|
|
|
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(
|
|
|
|
1: string mountPoint,
|
|
|
|
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(
|
|
|
|
1: string mountPoint,
|
|
|
|
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(
|
|
|
|
1: string mountPoint,
|
|
|
|
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(
|
|
|
|
1: string mountPoint,
|
|
|
|
2: string path,
|
|
|
|
) 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(
|
|
|
|
1: string mountPoint,
|
|
|
|
)
|
|
|
|
|
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(
|
|
|
|
1: string mountPoint,
|
|
|
|
2: i64 inodeNumber,
|
|
|
|
) throws (1: EdenError ex)
|
|
|
|
|
2017-10-17 02:22:27 +03:00
|
|
|
/**
|
|
|
|
* Sets the log level for a given category at runtime.
|
|
|
|
*/
|
2017-10-25 19:38:07 +03:00
|
|
|
SetLogLevelResult debugSetLogLevel(
|
2017-10-17 02:22:27 +03:00
|
|
|
1: string category,
|
|
|
|
2: string level,
|
|
|
|
) 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(
|
2017-06-17 02:08:19 +03:00
|
|
|
1: string mountPoint,
|
|
|
|
2: string 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(
|
|
|
|
1: string mountPoint,
|
|
|
|
2: string path
|
|
|
|
)
|
|
|
|
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)
|
2016-05-12 23:43:17 +03:00
|
|
|
}
|