martinvonz/jj
1
1
Fork 0
mirror of https://github.com/martinvonz/jj.git synced 2024-09-21 10:50:22 +03:00
Code Issues Packages Projects Releases Wiki Activity
720677c7f3
jj/lib/Cargo.toml

45 lines
1.0 KiB
TOML
Raw Normal View History

import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
[package]
project: rename project from Jujube to Jujutsu "Jujutsu" is probably much more familiar and relatable to most people. Also, I'm still not sure how "jujube" is supposed to be pronounced :P
2021-05-15 19:16:31 +03:00
name = "jujutsu-lib"
project: bump version to 0.2.0 for release under new name We need to release on crates.io before the new name gets taken. Besides, a *lot* has improved since the previous release.
2021-05-15 20:28:40 +03:00
version = "0.2.0"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
authors = ["Martin von Zweigbergk <martinvonz@google.com>"]
edition = "2018"
cargo: fill in crates.io metadata
2021-01-03 19:45:07 +03:00
license = "Apache-2.0"
project: rename project from Jujube to Jujutsu "Jujutsu" is probably much more familiar and relatable to most people. Also, I'm still not sure how "jujube" is supposed to be pronounced :P
2021-05-15 19:16:31 +03:00
description = "Library for Jujutsu (an experimental VCS)"
cargo: fill in crates.io metadata
2021-01-03 19:45:07 +03:00
homepage = "https://github.com/martinvonz/jj"
repository = "https://github.com/martinvonz/jj"
project: rename project from Jujube to Jujutsu "Jujutsu" is probably much more familiar and relatable to most people. Also, I'm still not sure how "jujube" is supposed to be pronounced :P
2021-05-15 19:16:31 +03:00
documentation = "https://docs.rs/jujutsu"
cargo: fill in crates.io metadata
2021-01-03 19:45:07 +03:00
readme = "../README.md"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
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 10:12:18 +03:00
[build-dependencies]
cargo: upgrade to protobuf 2.22.1 to avoid workaround for rustfmt::skip
2021-03-18 23:04:30 +03:00
protobuf-codegen-pure = "2.22.1"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
[dependencies]
git_store: use exponential backoff when retrying note-writing I have never run into this being a problem in practice, but this change is a stepping stone for two things: 1. Using exponential backoff for other locks (in particular the working copy). 2. Making the Git store write a ref for conflict objects, so they don't get GC'd (I want to do that before even I start dogfooding).
2020-12-25 09:56:05 +03:00
backoff = "0.2.1"
cargo: update blake2 For no reason other than to stay up to date.
2020-12-24 12:15:38 +03:00
blake2 = "0.9.1"
cargo: update dependencies For no reason other than to stay up to date.
2020-12-24 07:55:12 +03:00
bytes = "1.0.0"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
byteorder = "1.3.4"
cargo: update dependencies For no reason other than to stay up to date.
2020-12-24 07:55:12 +03:00
chrono = "0.4.19"
config = "0.10.1"
dirs = "3.0.1"
git2 = "0.13.14"
hex = "0.4.2"
cleanup: remove some Vec<_> annotations, mostly by using collect_vec()
2021-06-09 23:57:48 +03:00
itertools = "0.10.1"
tests: start using the maplit crate
2020-12-23 20:39:09 +03:00
maplit = "1.0.2"
revsets: define grammar in pest
2021-04-15 02:54:27 +03:00
pest = "2.1.3"
pest_derive = "2.1.0"
cargo: upgrade to protobuf 2.22.1 to avoid workaround for rustfmt::skip
2021-03-18 23:04:30 +03:00
protobuf = { version = "2.22.1", features = ["with-bytes"] }
cargo: update dependencies For no reason other than to stay up to date.
2020-12-24 07:55:12 +03:00
rand = "0.8.0"
gitignores: add own implementation and stop using libgit2's This is to address issue #8. I haven't added the optimization to avoid walking all the files in `target/` yet. Even so, this patch still speeds up `jj st` in this repo, with ~13k files in `target/`, from ~320 ms to ~100 ms (-5.1dB). The time actually checking if paths match gitignores seems to go down from 116 ms to 6 ms. I think that's mostly because libgit2 has to look for `.gitignore` files in every parent directory every time we ask it about a file, while the rewritten code looks for a `.gitignore` file only when visiting a new directory.
2021-05-12 19:43:58 +03:00
regex = "1.5.4"
cargo: update dependencies For no reason other than to stay up to date.
2020-12-24 07:55:12 +03:00
serde_json = "1.0.60"
tempfile = "3.1.0"
thiserror = "1.0.22"
uuid = { version = "0.8.1", features = ["v4"] }
whoami = "1.0.1"
zstd = "0.6.0"
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 11:00:42 +03:00
[dev-dependencies]
tests: use one thread per core in concurrency tests The tests have been failing in GitHub's CI quite frequently. It's about time I try to do something about it. Let's see if this helps.
2021-04-29 09:51:58 +03:00
num_cpus = "1.13.0"
cargo: update `test-case` to 1.2.0 now that frondeus/test-case#66 is fixed
2021-06-28 22:09:54 +03:00
test-case = "1.2.0"
Reference in New Issue Copy Permalink