mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-10-23 15:00:17 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
jj/lib/testutils/Cargo.toml

26 lines
749 B
TOML
Raw Normal View History

tests: move `testutils` module into separate crate The `testutils` module should ideally not be part of the library dependencies. Since they're used by the integration tests (and the CLI tests), we need to move them to a separate crate to achieve that.
2022-11-08 12:35:16 +00:00
[package]
name = "testutils"
cargo: rename crates from `jujutsu`/`jujutsu-lib` to `jj-cli`/`jj-lib` Almost everyone calls the project "jj", and there seeems to be consensus that we should rename the crates. I originally wanted the crates to be called `jj` and `jj-lib`, but `jj` was already taken. `jj-cli` is probably at least as good for it anyway. Once we've published a 0.8.0 under the new names, we'll release 0.7.1 versions under the old names with pointers to the new crates names.
2023-06-28 14:12:40 +00:00
description = "Integration test utils for the jj-lib crate"
tests: move `testutils` module into separate crate The `testutils` module should ideally not be part of the library dependencies. Since they're used by the integration tests (and the CLI tests), we need to move them to a separate crate to achieve that.
2022-11-08 12:35:16 +00:00
publish = false
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 16:41:42 +00:00
version = { workspace = true }
edition = { workspace = true }
rust-version = { workspace = true }
license = { workspace = true }
homepage = { workspace = true }
repository = { workspace = true }
documentation = { workspace = true }
readme = { workspace = true }
cargo: unify a lot of crate metadata in the workspace Summary: There's no need to go around specifying `rust-version` or `edition` or `version` several times, now that we have a global workspace. Instead, inherit workspace metadata from the top-level Cargo.toml file. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: Iaf905445978ed2b3377239dcdb8a6c32
2023-08-05 22:14:11 +00:00
tests: move `testutils` module into separate crate The `testutils` module should ideally not be part of the library dependencies. Since they're used by the integration tests (and the CLI tests), we need to move them to a separate crate to achieve that.
2022-11-08 12:35:16 +00:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
backend: make read functions async The commit backend at Google is cloud-based (and so are the other backends); it reads and writes commits from/to a server, which stores them in a database. That makes latency much higher than for disk-based backends. To reduce the latency, we have a local daemon process that caches and prefetches objects. There are still many cases where latency is high, such as when diffing two uncached commits. We can improve that by changing some of our (jj's) algorithms to read many objects concurrently from the backend. In the case of tree-diffing, we can fetch one level (depth) of the tree at a time. There are several ways of doing that: * Make the backend methods `async` * Use many threads for reading from the backend * Add backend methods for batch reading I don't think we typically need CPU parallelism, so it's wasteful to have hundreds of threads running in order to fetch hundreds of objects in parallel (especially when using a synchronous backend like the Git backend). Batching would work well for the tree-diffing case, but it's not as composable as `async`. For example, if we wanted to fetch some commits at the same time as we were doing a diff, it's hard to see how to do that with batching. Using async seems like our best bet. I didn't make the backend interface's write functions async because writes are already async with the daemon we have at Google. That daemon will hash the object and immediately return, and then send the object to the server in the background. I think any cloud-based solution will need a similar daemon process. However, we may need to reconsider this if/when jj gets used on a server with a custom backend that writes directly to a database (i.e. no async daemon in between). I've tried to measure the performance impact. That's the largest difference I've been able to measure was on `jj diff --ignore-working-copy -s --from v5.0 --to v6.0` in the Linux repo, which increases from 749 ms to 773 ms (3.3%). In most cases I've tested, there's no measurable difference. I've tried diffing from the root commit, as well as `jj --ignore-working-copy log --no-graph -r '::v3.0 & author(torvalds)' -T 'commit_id ++ "\n"'` (to test a commit-heavy load).
2023-09-06 19:59:17 +00:00
async-trait = { workspace = true }
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 16:41:42 +00:00
config = { workspace = true }
git2 = { workspace = true }
sign: Implement a test signing backend and add a few basic tests
2023-11-25 23:36:21 +00:00
hex = { workspace = true }
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 16:41:42 +00:00
itertools = { workspace = true }
backend: add error variant for access denied, handle when diffing Some backends, like the one we have at Google, can restrict access to certain files. For such files, if they return a regular `BackendError::ReadObject`, then that will terminate iteration in many cases (e.g. when diffing or listing files). This patch adds a new error variant for them to return instead, plus handling of such errors in diff output and in the working copy. In order to test the feature, I added a new commit backend that returns the new `ReadAccessDenied` error when the caller tries to read certain objects.
2024-03-19 17:56:31 +00:00
jj-lib = { workspace = true, features = ["testing"] }
Use `{ workspace = true }` to appease VS Code's `Cargo.toml` parser The VS Code "Better TOML" plugin (which I think most of our VS Code developers use?) doesn't support the `x.y = z` syntax at the top level, even though it's valid TOML. This is also useful if we ever want to add additional properties in different sub-crates (although unlikely for the near future).
2023-08-22 16:41:42 +00:00
rand = { workspace = true }
tempfile = { workspace = true }
Reference in a new issue Copy permalink