2016-05-12 23:43:17 +03:00
|
|
|
/*
|
2017-01-21 09:02:33 +03:00
|
|
|
* Copyright (c) 2016-present, Facebook, Inc.
|
2016-05-12 23:43:17 +03:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This source code is licensed under the BSD-style license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
* of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include "common/fb303/cpp/FacebookBase2.h"
|
2017-03-02 10:02:33 +03:00
|
|
|
#include "eden/fs/service/gen-cpp2/StreamingEdenService.h"
|
2017-04-14 21:31:48 +03:00
|
|
|
#include "eden/fs/utils/PathFuncs.h"
|
2016-05-12 23:43:17 +03:00
|
|
|
|
2017-01-18 02:01:44 +03:00
|
|
|
namespace folly {
|
|
|
|
template <typename T>
|
|
|
|
class Future;
|
|
|
|
}
|
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
namespace facebook {
|
|
|
|
namespace eden {
|
|
|
|
|
2017-01-18 02:01:44 +03:00
|
|
|
class Hash;
|
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
|
|
|
class EdenMount;
|
2016-05-12 23:43:17 +03:00
|
|
|
class EdenServer;
|
2016-09-19 22:48:09 +03:00
|
|
|
class TreeInode;
|
2016-05-12 23:43:17 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Handler for the EdenService thrift interface
|
|
|
|
*/
|
2017-03-02 10:02:33 +03:00
|
|
|
class EdenServiceHandler : virtual public StreamingEdenServiceSvIf,
|
2016-05-12 23:43:17 +03:00
|
|
|
public facebook::fb303::FacebookBase2 {
|
|
|
|
public:
|
|
|
|
explicit EdenServiceHandler(EdenServer* server);
|
|
|
|
|
|
|
|
facebook::fb303::cpp2::fb_status getStatus() override;
|
|
|
|
|
|
|
|
void mount(std::unique_ptr<MountInfo> info) override;
|
|
|
|
|
2016-05-28 03:40:10 +03:00
|
|
|
void unmount(std::unique_ptr<std::string> mountPoint) override;
|
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
void listMounts(std::vector<MountInfo>& results) override;
|
|
|
|
|
2017-04-28 03:30:14 +03:00
|
|
|
void getParentCommits(
|
|
|
|
WorkingDirectoryParents& result,
|
2017-02-22 23:19:04 +03:00
|
|
|
std::unique_ptr<std::string> mountPoint) override;
|
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
void checkOutRevision(
|
2017-02-16 07:31:48 +03:00
|
|
|
std::vector<CheckoutConflict>& results,
|
2016-05-12 23:43:17 +03:00
|
|
|
std::unique_ptr<std::string> mountPoint,
|
2017-02-16 07:31:48 +03:00
|
|
|
std::unique_ptr<std::string> hash,
|
|
|
|
bool force) override;
|
2016-05-12 23:43:17 +03:00
|
|
|
|
2017-04-28 03:30:14 +03:00
|
|
|
void resetParentCommits(
|
2017-04-07 03:44:06 +03:00
|
|
|
std::unique_ptr<std::string> mountPoint,
|
2017-04-28 03:30:14 +03:00
|
|
|
std::unique_ptr<WorkingDirectoryParents> parents) override;
|
2017-04-07 03:44:06 +03:00
|
|
|
|
2016-09-13 04:27:54 +03:00
|
|
|
void getBindMounts(
|
|
|
|
std::vector<std::string>& out,
|
|
|
|
std::unique_ptr<std::string> mountPoint) override;
|
|
|
|
|
2016-05-28 04:16:27 +03:00
|
|
|
void getSHA1(
|
2016-08-18 17:21:36 +03:00
|
|
|
std::vector<SHA1Result>& out,
|
2016-05-28 04:16:27 +03:00
|
|
|
std::unique_ptr<std::string> mountPoint,
|
2016-08-18 17:21:36 +03:00
|
|
|
std::unique_ptr<std::vector<std::string>> paths) override;
|
2016-05-28 04:16:27 +03:00
|
|
|
|
2016-09-19 22:48:14 +03:00
|
|
|
void getCurrentJournalPosition(
|
|
|
|
JournalPosition& out,
|
|
|
|
std::unique_ptr<std::string> mountPoint) override;
|
|
|
|
|
2016-09-19 22:48:15 +03:00
|
|
|
void getFilesChangedSince(
|
|
|
|
FileDelta& out,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<JournalPosition> fromPosition) override;
|
|
|
|
|
2016-09-20 00:08:47 +03:00
|
|
|
void getFileInformation(
|
|
|
|
std::vector<FileInformationOrError>& out,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::vector<std::string>> paths) override;
|
|
|
|
|
2017-01-26 23:45:50 +03:00
|
|
|
void glob(
|
|
|
|
std::vector<std::string>& out,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::vector<std::string>> globs) override;
|
|
|
|
|
2017-03-21 23:25:30 +03:00
|
|
|
void async_tm_subscribe(
|
|
|
|
std::unique_ptr<apache::thrift::StreamingHandlerCallback<
|
|
|
|
std::unique_ptr<JournalPosition>>> callback,
|
|
|
|
std::unique_ptr<std::string> mountPoint) override;
|
|
|
|
|
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
|
|
|
void getManifestEntry(
|
|
|
|
ManifestEntry& out,
|
2017-08-22 03:51:48 +03:00
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::string> relativePath) override;
|
2017-08-19 07:36: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
|
|
|
folly::Future<std::unique_ptr<ScmStatus>> future_getScmStatus(
|
Reimplement dirstate used by Eden's Hg extension as a subclass of Hg's dirstate.
Summary:
This is a major change to Eden's Hg extension.
Our initial attempt to implement `edendirstate` was to create a "clean room"
implementation that did not share code with `mercurial/dirstate.py`. This was
helpful in uncovering the subset of the dirstate API that matters for Eden. It
also provided a better safeguard against upstream changes to `dirstate.py` in
Mercurial itself.
In this implementation, the state transition management was mostly done
on the server in `Dirstate.cpp`. We also made a modest attempt to make
`Dirstate.cpp` "SCM-agnostic" such that the same APIs could be used for
Git at some point.
However, as we have tried to support more of the sophisticated functionality
in Mercurial, particularly `hg histedit`, achieving parity between the clean room
implementation and Mercurial's internals has become more challenging.
Ultimately, the clean room implementation is likely the right way to go for Eden,
but for now, we need to prioritize having feature parity with vanilla Hg when
using Eden. Once we have a more complete set of integration tests in place,
we can reimplement Eden's dirstate more aggressively to optimize things.
Fortunately, the [[ https://bitbucket.org/facebook/hg-experimental/src/default/sqldirstate/ | sqldirstate ]]
extension has already demonstrated that it is possible to provide a faithful
dirstate implementation that subclasses the original `dirstate` while using a different
storage mechanism. As such, I used `sqldirstate` as a model when implementing
the new `eden_dirstate` (distinguishing it from our v1 implementation, `edendirstate`).
In particular, `sqldirstate` uses SQL tables as storage for the following private fields
of `dirstate`: `_map`, `_dirs`, `_copymap`, `_filefoldmap`, `_dirfoldmap`. Because
`_filefoldmap` and `_dirfoldmap` exist to deal with case-insensitivity issues, we
do not support them in `eden_dirstate` and add code to ensure the codepaths that
would access them in `dirstate` never get exercised. Similarly, we also implemented
`eden_dirstate` so that it never accesses `_dirs`. (`_dirs` is a multiset of all directories in the
dirstate, which is an O(repo) data structure, so we do not want to maintain it in Eden.
It appears to be primarily used for checking whether a path to a file already exists in
the dirstate as a directory. We can protect against that in more efficient ways.)
That leaves only `_map` and `_copymap` to worry about. `_copymap` contains the set
of files that have been marked "copied" in the current dirstate, so it is fairly small and
can be stored on disk or in memory with little concern. `_map` is a bit trickier because
it is expected to have an entry for every file in the dirstate. In `sqldirstate`, it is stored
across two tables: `files` and `nonnormalfiles`. For Eden, we already represent the data
analogous to the `files` table in RocksDB/the overlay, so we do not need to create a new
equivalent to the `files` table. We do, however, need an equivalent to the `nonnormalfiles`
table, which we store in as Thrift-serialized data in an ordinary file along with the `_copymap`
data.
In our Hg extension, our implementation of `_map` is `eden_dirstate_map`, which is defined
in a Python file of the same name. Our implementation of `_copymap` is `dummy_copymap`,
which is defined in `eden_dirstate.py`. Both of these collections are simple pass-through data
structures that translate their method calls to Thrift server calls. I expect we will want to
optimize this in the future via some client-side caching, as well as creating batch APIs for talking
to the server via Thrift.
One advantage of this new implementation is that it enables us to delete
`eden/hg/eden/overrides.py`, which overrode the entry points for `hg add` and `hg remove`.
Between the recent implementation of `dirstate.walk()` for Eden and this switch
to the real dirstate, we can now use the default implementation of `hg add` and `hg remove`
(although we have to play some tricks, like in the implementation of `eden_dirstate.status()`
in order to make `hg remove` work).
In the course of doing this revision, I discovered that I had to make a minor fix to
`EdenMatchInfo.make_glob_list()` because `hg add foo` was being treated as
`hg add foo/**/*` even when `foo` was just a file (as opposed to a directory), in which
case the glob was not matching `foo`!
I also had to do some work in `eden_dirstate.status()` in which the `match` argument
was previously largely ignored. It turns out that `dirstate.py` uses `status()` for a number
of things with the `match` specified as a filter, so the output of `status()` must be filtered
by `match` accordingly. Ultimately, this seems like work that would be better done on the
server, but for simplicity, we're just going to do it in Python, for now.
For the reasons explained above, this revision deletes a lot of code `Dirstate.cpp`.
As such, `DirstateTest.cpp` does not seem worth refactoring, though the scenarios it was
testing should probably be converted to integration tests. At a high level, the role of
`DirstatePersistence` has not changed, but the exact data it writes is much different.
Its corresponding unit test is also disabled, for now.
Note that this revision does not change the name of the file where "dirstate data" is written
(this is defined as `kDirstateFile` in `ClientConfig.cpp`), so we should blow away any existing
instances of this file once this change lands. (It is still early enough in the project that it does
not seem worth the overhead of a proper migration.)
The true test of the success of this new approach is the ease with which we can write more
integration tests for things like `hg histedit` and `hg graft`. Ideally, these should require very
few changes to `eden_dirstate.py`.
Reviewed By: simpkins
Differential Revision: D5071778
fbshipit-source-id: e8fec4d393035d80f36516ac050cad025dc3ba31
2017-05-26 21:51:30 +03:00
|
|
|
std::unique_ptr<std::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
|
|
|
bool listIgnored) override;
|
2016-11-26 23:00:16 +03:00
|
|
|
|
2017-04-04 01:47:53 +03:00
|
|
|
void debugGetScmTree(
|
|
|
|
std::vector<ScmTreeEntry>& entries,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::string> id,
|
|
|
|
bool localStoreOnly) override;
|
|
|
|
|
|
|
|
void debugGetScmBlob(
|
|
|
|
std::string& data,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::string> id,
|
|
|
|
bool localStoreOnly) override;
|
|
|
|
|
|
|
|
void debugGetScmBlobMetadata(
|
|
|
|
ScmBlobMetadata& metadata,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::string> id,
|
|
|
|
bool localStoreOnly) override;
|
|
|
|
|
|
|
|
void debugInodeStatus(
|
|
|
|
std::vector<TreeInodeDebugInfo>& inodeInfo,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::string> path) override;
|
|
|
|
|
2017-08-17 05:56:32 +03:00
|
|
|
void debugGetInodePath(
|
|
|
|
InodePathDebugInfo& inodePath,
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
int64_t inodeNumber) override;
|
|
|
|
|
2017-10-17 02:22:27 +03:00
|
|
|
void debugSetLogLevel(
|
2017-10-25 19:38:07 +03:00
|
|
|
SetLogLevelResult& result,
|
2017-10-17 02:22:27 +03:00
|
|
|
std::unique_ptr<std::string> category,
|
|
|
|
std::unique_ptr<std::string> level) override;
|
|
|
|
|
2017-08-23 05:43:31 +03:00
|
|
|
int64_t unloadInodeForPath(
|
2017-06-17 02:08:19 +03:00
|
|
|
std::unique_ptr<std::string> mountPoint,
|
2017-08-23 05:43:29 +03:00
|
|
|
std::unique_ptr<std::string> path,
|
|
|
|
std::unique_ptr<TimeSpec> age) override;
|
2017-08-18 21:43:57 +03:00
|
|
|
|
|
|
|
void flushStatsNow() override;
|
|
|
|
|
2017-08-22 01:52:55 +03:00
|
|
|
void invalidateKernelInodeCache(
|
|
|
|
std::unique_ptr<std::string> mountPoint,
|
|
|
|
std::unique_ptr<std::string> path) override;
|
|
|
|
|
2017-08-25 22:41:41 +03:00
|
|
|
void getStatInfo(InternalStats& result) override;
|
|
|
|
|
2016-06-11 00:15:26 +03:00
|
|
|
/**
|
|
|
|
* When this Thrift handler is notified to shutdown, it notifies the
|
|
|
|
* EdenServer to shut down, as well.
|
|
|
|
*/
|
|
|
|
void shutdown() override;
|
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
private:
|
|
|
|
// Forbidden copy constructor and assignment operator
|
|
|
|
EdenServiceHandler(EdenServiceHandler const&) = delete;
|
|
|
|
EdenServiceHandler& operator=(EdenServiceHandler const&) = delete;
|
|
|
|
|
2017-01-18 02:01:44 +03:00
|
|
|
folly::Future<Hash> getSHA1ForPath(
|
|
|
|
folly::StringPiece mountPoint,
|
|
|
|
folly::StringPiece path);
|
2016-08-18 17:21:36 +03:00
|
|
|
|
2017-01-18 02:01:44 +03:00
|
|
|
folly::Future<Hash> getSHA1ForPathDefensively(
|
|
|
|
folly::StringPiece mountPoint,
|
|
|
|
folly::StringPiece path) noexcept;
|
2016-08-18 17:21:36 +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 `filename` exists in the manifest as a file (not a directory), returns
|
|
|
|
* the mode of the file as recorded in the manifest.
|
|
|
|
*/
|
|
|
|
folly::Optional<mode_t> isInManifestAsFile(
|
|
|
|
const EdenMount* mount,
|
|
|
|
const RelativePathPiece filename);
|
2016-11-26 23:00:16 +03:00
|
|
|
|
2016-05-12 23:43:17 +03:00
|
|
|
EdenServer* const server_;
|
|
|
|
};
|
2017-10-26 08:24:47 +03:00
|
|
|
} // namespace eden
|
|
|
|
} // namespace facebook
|