mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-12-26 14:00:51 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
jj/lib/Cargo.toml

98 lines
2.4 KiB
TOML
Raw Normal View History

import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
[package]
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
name = "jj-lib"
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
description = "Library for Jujutsu - an experimental version control system"
compile integration tests as a single binary this greatly speeds up the time to run all tests, at the cost of slightly larger recompile times for individual tests. this unfortunately adds the requirement that all tests are listed in `runner.rs` for the crate. to avoid forgetting, i've added a new test that ensures the directory is in sync with the file. ## benchmarks before this change, recompiling all tests took 32-50 seconds and running a single test took 3.5 seconds: ``` ; hyperfine 'touch lib/src/lib.rs && cargo t --test test_working_copy' Time (mean ± σ): 3.543 s ± 0.168 s [User: 2.597 s, System: 1.262 s] Range (min … max): 3.400 s … 3.847 s 10 runs ``` after this change, recompiling all tests take 4 seconds: ``` ; hyperfine 'touch lib/src/lib.rs ; cargo t --test runner --no-run' Time (mean ± σ): 4.055 s ± 0.123 s [User: 3.591 s, System: 1.593 s] Range (min … max): 3.804 s … 4.159 s 10 runs ``` and running a single test takes about the same: ``` ; hyperfine 'touch lib/src/lib.rs && cargo t --test runner -- test_working_copy' Time (mean ± σ): 4.129 s ± 0.120 s [User: 3.636 s, System: 1.593 s] Range (min … max): 3.933 s … 4.346 s 10 runs ``` about 1.4 seconds of that is the time for the runner, of which .4 is the time for the linker. so there may be room for further improving the times.
2024-02-02 07:55:24 +00:00
autotests = false
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
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 }
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
cargo: explicitly indicate paths to publish Running `cargo publish` from a non-colocated repo (such as my usual repo) is currently quite scary because it uploads all non-hidden files, even if they're ignored by `.gitignore` (https://github.com/rust-lang/cargo/issues/2063). I noticed this a while ago and have always run the command from a fresh clone since then. To avoid the need for that, let's use the workaround mentioned on the bug, which is to explicitly list patterns we want to publish.
2024-04-14 22:27:23 +00:00
include = [
"/LICENSE",
"/benches/",
"/src/",
"/tests/",
"!*.pending-snap",
"!*.snap*",
]
compile integration tests as a single binary this greatly speeds up the time to run all tests, at the cost of slightly larger recompile times for individual tests. this unfortunately adds the requirement that all tests are listed in `runner.rs` for the crate. to avoid forgetting, i've added a new test that ensures the directory is in sync with the file. ## benchmarks before this change, recompiling all tests took 32-50 seconds and running a single test took 3.5 seconds: ``` ; hyperfine 'touch lib/src/lib.rs && cargo t --test test_working_copy' Time (mean ± σ): 3.543 s ± 0.168 s [User: 2.597 s, System: 1.262 s] Range (min … max): 3.400 s … 3.847 s 10 runs ``` after this change, recompiling all tests take 4 seconds: ``` ; hyperfine 'touch lib/src/lib.rs ; cargo t --test runner --no-run' Time (mean ± σ): 4.055 s ± 0.123 s [User: 3.591 s, System: 1.593 s] Range (min … max): 3.804 s … 4.159 s 10 runs ``` and running a single test takes about the same: ``` ; hyperfine 'touch lib/src/lib.rs && cargo t --test runner -- test_working_copy' Time (mean ± σ): 4.129 s ± 0.120 s [User: 3.636 s, System: 1.593 s] Range (min … max): 3.933 s … 4.346 s 10 runs ``` about 1.4 seconds of that is the time for the runner, of which .4 is the time for the linker. so there may be room for further improving the times.
2024-02-02 07:55:24 +00:00
[[test]]
name = "runner"
benches: move diff_bench to lib crate It has no dependency on the cli crate.
2023-03-27 08:23:27 +00:00
[[bench]]
name = "diff_bench"
harness = false
protobuf: generate code at build-time I had tried to generate the protobuf code at build time many months ago, but decided against it because it slowed down the build too much. I didn't realize there was the "cargo:rerun-if-changed=<filename>" feature that time. Given that that exists, it seems like an obvious win to generate the source code at build time. I put the generated sources in `$OUT_DIR` (where [1] says they should be), then include them in the `protos` module by using the `include!` macro. The biggest problem with that is that I couldn't get IntelliJ to understand it, even after enabling the experimental features described in [2]. [1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#code-generation [2] https://github.com/intellij-rust/intellij-rust/issues/1908#issuecomment-592773865
2020-12-24 07:12:18 +00:00
[build-dependencies]
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_check = { workspace = true }
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
[dependencies]
async: switch to `pollster`'s `block_on()` During the transition to using more async code, I keep running into https://github.com/rust-lang/futures-rs/issues/2090. Right now, I want to convert `MergedTree::diff()` into a `Stream`. I don't want to update all call sites at once, so instead I'm adding a `MergedTree::diff_stream()` method, which just wraps `MergedTree::diff()` in a `Stream. However, since the iterator is synchronous, it needs to block on the async `Backend::read_tree()` calls. If we then also block on the `Stream` in the CLI, we run into the panic.
2023-10-28 23:15:01 +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
backoff = { workspace = true }
blake2 = { workspace = true }
bytes = { workspace = true }
chrono = { workspace = true }
config = { workspace = true }
digest = { workspace = true }
either = { workspace = true }
cargo: sort dependencies list alphabetically
2023-11-07 07:15:31 +00:00
futures = { 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
git2 = { workspace = true }
cargo: add gitoxide (or gix) dependency I've enabled the "index" component from the "basic" feature set, which would be needed to implement colocated repo functionality. The doc suggests that a library shouldn't activate "max-performance-safe", but our crate is also an application so it would be okay to enable the feature. We'll need "parallel" anyway to make GitBackend Sync. https://docs.rs/gix/latest/gix/#feature-flags
2023-10-29 07:21:37 +00:00
gix = { workspace = true }
revset: add support for glob:pattern
2023-10-19 17:46:26 +00:00
glob = { 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
hex = { workspace = true }
Switch to ignore crate for gitignore handling. Co-authored-by: Waleed Khan <me@waleedkhan.name>
2024-02-16 17:54:09 +00:00
ignore = { 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 }
Implement a procedural macro to derive the ContentHash trait for structs This is a no-op in terms of function, but provides a nicer way to derive the ContentHash trait for structs using the `#[derive(ContentHash)]` syntax used for other traits such as `Debug`. This commit only adds the macro. A subsequent commit will replace uses of `content_hash!{}` with `#[derive(ContentHash)]`. The new macro generates nice error messages, just like the old macro: ``` error[E0277]: the trait bound `NotImplemented: content_hash::ContentHash` is not satisfied --> lib/src/content_hash.rs:265:16 | 265 | z: NotImplemented, | ^^^^^^^^^^^^^^ the trait `content_hash::ContentHash` is not implemented for `NotImplemented` | = help: the following other types implement trait `content_hash::ContentHash`: bool i32 i64 u8 u32 u64 std::collections::HashMap<K, V> BTreeMap<K, V> and 38 others ``` This commit does two things to make proc macros re-exported by jj_lib useable by deps: 1. jj_lib needs to be able refer to itself as `jj_lib` which it does by adding an `extern crate self as jj_lib` declaration. 2. jj_lib::content_hash needs to re-export the `digest::Update` type so that users of jj_lib can use the `#[derive(ContentHash)]` proc macro without directly depending on the digest crate. This is done by re-exporting it as `DigestUpdate`. #3054
2024-02-13 23:10:30 +00:00
jj-lib-proc-macros = { 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
maplit = { workspace = true }
once_cell = { workspace = true }
pest = { workspace = true }
pest_derive = { workspace = true }
async: switch to `pollster`'s `block_on()` During the transition to using more async code, I keep running into https://github.com/rust-lang/futures-rs/issues/2090. Right now, I want to convert `MergedTree::diff()` into a `Stream`. I don't want to update all call sites at once, so instead I'm adding a `MergedTree::diff_stream()` method, which just wraps `MergedTree::diff()` in a `Stream. However, since the iterator is synchronous, it needs to block on the async `Backend::read_tree()` calls. If we then also block on the `Stream` in the CLI, we run into the panic.
2023-10-28 23:15:01 +00:00
pollster = { 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
prost = { workspace = true }
rand = { workspace = true }
rand_chacha = { workspace = true }
rayon = { workspace = true }
cargo: add ref-cast dependency It helps to implement transparent conversion from &str to &Wrapped(str). We could instead wrap the reference as Wrapped<'a>(&'a str), but it has various drawbacks. Notably we can't implement Borrow and Deref because these traits require a reference in return position. Since the unsafe bits are pretty small, we can instead implement cast functions without using the ref-cast crate. However, I believe we'll trust ref-cast more than hand-crafted unsafe code. https://crates.io/crates/ref-cast https://docs.rs/ref-cast/1.0.20/ref_cast/attr.ref_cast_custom.html
2023-11-25 09:05:55 +00:00
ref-cast = { 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
regex = { workspace = true }
serde = { workspace = true }
serde_json = { workspace = true }
smallvec = { workspace = true }
strsim = { workspace = true }
tempfile = { workspace = true }
thiserror = { workspace = true }
cargo: unify dependency versions through workspace deps Summary: This moves all dependencies across the jj-lib and jj-cli crates into the top-level Cargo file; with that, we can change each crate instead to just inherit the workspace version, with the toggled features enabled, by setting a dependency such as: dep.workspace = true in the relevant Cargo.toml file. This doesn't actually change any of the build semantics (from what I can tell) nor the lockfile, and seems to respond normally. There are more cleanups that can follow. Two notes: - Dependabot seems to work fine, based on what I've seen in other repos. - `cargo add` doesn't seem to know how to add packages to a top-level `workspace.dependencies` field; instead you can `cargo add -p jj-cli` and move the entries, at least. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I307827e5f15c0d8ea8e2a80ec793d3c7
2023-08-05 16:14:11 +00:00
tokio = { workspace = true, optional = 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
tracing = { workspace = true }
cargo: unify dependency versions through workspace deps Summary: This moves all dependencies across the jj-lib and jj-cli crates into the top-level Cargo file; with that, we can change each crate instead to just inherit the workspace version, with the toggled features enabled, by setting a dependency such as: dep.workspace = true in the relevant Cargo.toml file. This doesn't actually change any of the build semantics (from what I can tell) nor the lockfile, and seems to respond normally. There are more cleanups that can follow. Two notes: - Dependabot seems to work fine, based on what I've seen in other repos. - `cargo add` doesn't seem to know how to add packages to a top-level `workspace.dependencies` field; instead you can `cargo add -p jj-cli` and move the entries, at least. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: I307827e5f15c0d8ea8e2a80ec793d3c7
2023-08-05 16:14:11 +00:00
watchman_client = { workspace = true, optional = 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
whoami = { workspace = true }
zstd = { workspace = true }
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
lib: use advisory locks on Unix targets Allows automatic recovery when encountering stale lockfiles, and more efficient blocking rather than polling for fresh ones. The previous implementation is preserved for other platforms.
2023-05-06 01:54:33 +00:00
[target.'cfg(unix)'.dependencies]
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
rustix = { workspace = true }
lib: use advisory locks on Unix targets Allows automatic recovery when encountering stale lockfiles, and more efficient blocking rather than polling for fresh ones. The previous implementation is preserved for other platforms.
2023-05-06 01:54:33 +00:00
working_copy: implement symlinks on windows with a helper function enables symlink tests on windows, ignoring failures due to disabled developer mode, and updates windows.md
2024-02-04 08:03:03 +00:00
[target.'cfg(windows)'.dependencies]
winreg = { workspace = true }
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
[dev-dependencies]
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
assert_matches = { workspace = true }
criterion = { workspace = true }
esl01-renderdag = { workspace = true }
test_conflicts and test_resolve_command: use `indoc!` to indent conflict markers in tests Apart from (IMO) looking nicer, this will also sidestep the potential problem that if the file contains actual jj conflict markers (`>>>>>>>` in the beginning of a line, for example), jj would currently have trouble materializing and subsequently parsing conflicts in the file if it actually became conflicted. I'll demo this bug in either this or a subsequent PR. It's the kind of bug that sounds serious in theory but might never cause a problem in practice. After this PR, only `docs/tutorial.md` has a conflict marker that's not indented. There's only one there, so hopefully it won't be too much of a pain to deal with. I also indented other strings in `test_conflicts.rs`. IMO, this looks nice and more consistent with the `insta::assert_snapshot` output. I didn't spend the time to do the same for `test_resolve_command`.
2024-03-23 02:34:28 +00:00
indoc = { 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
insta = { workspace = true }
num_cpus = { workspace = true }
merged_tree: add diff iterator If we're going to be able to replace most instances of `Tree` by `MergedTree`, we'll need to be able to diff two `MergedTree`s. This implements support for that. The implementation copies a lot from the diff iterator we have for `Tree`. I suspect we should be able to reuse some of the code by introducing some traits that can then be implemented by both `Tree` and `MergedTree`. I've left a TODO about that.
2023-07-06 06:03:55 +00:00
pretty_assertions = { 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
test-case = { workspace = true }
testutils = { workspace = true }
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
tokio = { workspace = true, features = ["full"] }
cargo: use libgit2 with vendored OpenSSL (#73) I was able to build a working musl binary with this change, by running this command: ``` cargo build --release --target x86_64-unknown-linux-musl ``` Thanks to @arxanas for the tip.
2022-03-13 07:03:44 +00:00
[features]
op_store: drop support for upgrading from Thrift implementation
2023-03-29 18:13:28 +00:00
default = []
cargo: use libgit2 with vendored OpenSSL (#73) I was able to build a working musl binary with this change, by running this command: ``` cargo build --release --target x86_64-unknown-linux-musl ``` Thanks to @arxanas for the tip.
2022-03-13 07:03:44 +00:00
vendored-openssl = ["git2/vendored-openssl"]
feat(fsmonitor): Watchman filesystem monitor implementation
2023-07-08 09:23:32 +00:00
watchman = ["dep:tokio", "dep:watchman_client"]
revset: add count_estimate() to Revset trait The count() function in this trait is used by "jj branch" to determine (and then report) how many commits a certain branch is ahead/behind another branch. This is currently implemented by walking all commits in the revset, counting how many were encountered. But this could be improved: if the number is large, it is probably sufficient to report "at least N" (instead of walking all the way), and this does not scale well to jj backends that may not have all commits present locally (which may prefer to return an estimate, rather than access the network). Therefore, add a function that is explicitly documented to be O(1) and that can return a range of values if the backend so chooses. Also remove count(), as it is not immediately obvious that it is an expensive call, and callers that are willing to pay the cost can obtain the exact same functionality through iter().count() anyway. (In this commit, all users of count() are migrated to iter().count() to preserve all existing functionality; they will be migrated to count_estimate() in a subsequent commit.) "branch" needed to be updated due to this change. Although jj is currently only available in English, I have attempted to keep user-visible text from being assembled piece by piece, so that if we later decide to translate jj into other languages, things will be easier for translators.
2024-01-16 22:12:02 +00:00
testing = []
Reference in a new issue Copy permalink