facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-05 22:37:37 +03:00
Code Issues Projects Releases Wiki Activity
A Scalable, User-Friendly Source Control System.
154 Commits 24 Branches 62 Tags 318 MiB
Rust 45.1%
Python 20.7%
C++ 10.5%
Perl 9.1%
TypeScript 7.3%
Other 7.1%
07df3d8fbc
Go to file
Wez Furlong 07df3d8fbc additional query API for our thrift interface 
Summary:
This diff adds a couple more things to our thrift interface:

1. Introduces JournalPosition
2. Adds methods to query the current JournalPosition and obtain a
   delta since a given JournalPosition
3. Augments getMaterializedFiles to also return the current JournalPosition
4. Adds a method to evaluate a `glob` against Eden
5. Adds a method using thrift streaming to subscribe to realtime changes

Could probably finesse the naming a little bit.

The JournalPosition allows reasoning about changes to files that are not part
of an Eden snapshot.  Internally the journal position is just the
SequenceNumber from the journal datastructures, but when we expose it to
clients we need to be able to distinguish between a sequence number from the
current instance of the eden service and a prior incarnation (eg: if the
process has been restarted, and we have no way to recreate the journal we need
to be able to indicate this to the client if they ask about changes in that
range).   For the convenience of the client we also include the `toHash` (the
most recent hash from the journal entry) which is likely useful for the `hg`
dirstate operations; it is useful to know that the snapshot may have changed
since the last query about the dirstate.

The `getFileInformation` method returns the instantaneously available `stat()`
like information about the requested list of files.   Since we simply don't
have historical data on how files in the overlay looked (only how they look
now), this method does not allow passing in a JournalPosition.  When it comes
to comparing historical data, we will need to add an API that accepts two
snapshot hashes and generates the results from there.  This particular method
is geared up to understanding the current state of the world; the obvious use
case is plugging in the file list from `getFilesChangedSince` into this
function to figure out what's what.

* Do we want a function that combines `getFilesChangedSince` + `getFileInformation` into a single RPC?

Why is there a glob method?  It's to support a use-case in the watchman/buck
integration.  I'm just sketching it out in the thrift interface at this stage.
In the future we also need to be able to express how to carry out a tree walk,
but that will require some query predicates that I don't want to get hung up on
specifying immediately.

Why is the streaming stuff in its own thrift file?  We can't generate code for
it in java or perhaps also python.  It's only needed to plumb data into
watchman so it's broken out into its own definition.  Nothing depends on that
file yet, so it's probably not specified quite right.  The important thing is
how the subscribe method looks: it's essentially the same as the method to
query a delta, but it keeps emitting deltas as they are produced.  This is
another API that will benefit from query predicates when we get around to
specifying them.

I've added `JournalDelta::fromHash` and `JournalDelta::toHash` to hold the
appropriate snapshot ids in the journal entry; this will allow us to indicate
when we've checked out a new snapshot, or created a new snapshot.  We have
no way to populate these yet; I commented on D3762646 about storing the
`snapshotID` that we have during `EdenServiceHandler::mountImpl` into either
the `EdenMount` or the proposed `RootInode` class.  Once we have that we
can simply sample it and store it as we generate `JournalDelta`s.

Reviewed By: simpkins

Differential Revision: D3860804

fbshipit-source-id: 896c24c354e6f58328fb45c24b16915d9e937108
2016-09-26 13:52:25 -07:00
eden additional query API for our thrift interface 2016-09-26 13:52:25 -07:00
.buckconfig Exclude the cpp_binary for the daemon from the python_binary for the CLI. 2016-06-15 17:07:58 -07:00
.gitignore Initial commit 2016-05-12 14:09:13 -07:00
CONTRIBUTING.md Initial commit 2016-05-12 14:09:13 -07:00
DEFS change eden cli to run with python 3 2016-06-27 11:59:24 -07:00
install Exclude the cpp_binary for the daemon from the python_binary for the CLI. 2016-06-15 17:07:58 -07:00
LICENSE Initial commit 2016-05-12 14:09:13 -07:00
PATENTS Initial commit 2016-05-12 14:09:13 -07:00
README.md Fix a typo in Eden's README.md. 2016-05-13 09:32:03 -07:00

README.md

Eden

Eden is a project with several components, the most prominent of which is a virtual filesystem built using FUSE.

Caveat Emptor

Eden is still in early stages of development. We are making it available now because we plan to start making references to it from our other open source projects, such as Buck, Watchman, and Nuclide.

The version that we provide on GitHub does not build yet.

This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:

  • The reinterpretations of build macros in DEFS.
  • A process for including third-party dependencies (presumably via Git submodules) and wiring up the external_deps argument in the build macros to point to them.
  • Providing the toolchain needed to power the [undocumented] thrift_library() rule in Buck.

The goal is to get Eden building on both Linux and OS X, though Linux support is expected to come first.