2024-08-19 05:58:10 +00:00
|
|
|
# Roadmap
|
|
|
|
|
|
|
|
|
|
This documents some of the goals we have. Many of them are quite independent.
|
|
|
|
|
|
|
|
|
|
> **Note:** Most people contributing to Jujutsu do so in their spare time, which
|
|
|
|
|
> means that we cannot attach any target dates to any of the goals below.
|
|
|
|
|
|
|
|
|
|
## Support for copies and renames
|
|
|
|
|
|
|
|
|
|
We want to support copy tracing in a way that leaves it up to the commit backend
|
|
|
|
|
to either record or detect copies. That should let us work with existing Git
|
|
|
|
|
repos (Git does not record copies, it detects them on the fly) as well as with
|
|
|
|
|
very large repos where detection would be too slow. See
|
|
|
|
|
[design doc][copy-design-doc].
|
|
|
|
|
|
|
|
|
|
## Forge integrations
|
|
|
|
|
|
|
|
|
|
We would like to make it easier to work with various popular forges by providing
|
|
|
|
|
something like `jj github submit`, `jj gitlab submit`, and `jj gerrit send`. For
|
|
|
|
|
popular forges, we might include that support by default in the standard `jj`
|
|
|
|
|
binary.
|
|
|
|
|
|
|
|
|
|
## Submodule support
|
|
|
|
|
|
|
|
|
|
Git submodules are used frequently enough in large Git repos that we will
|
|
|
|
|
probably need to [support them][submodules]. There are still big open
|
|
|
|
|
questions around UX.
|
|
|
|
|
|
|
|
|
|
## Better Rust API for UIs
|
|
|
|
|
|
|
|
|
|
UIs like [gg] currently have to duplicate quite a bit of logic from `jj-cli`. We
|
|
|
|
|
need to make this code not specific to the CLI (e.g. return status objects
|
|
|
|
|
instead of printing messages) and move it into `jj-lib`.
|
|
|
|
|
|
|
|
|
|
## RPC API
|
|
|
|
|
|
|
|
|
|
One problem with writing tools using the Rust API is that they will only work
|
|
|
|
|
with the backends they were compiled with. For example, a regular [gg] build
|
|
|
|
|
will not work on Google repos because it doesn't have the backends necessary to
|
|
|
|
|
load them. We want to provide an RPC API for tools that want to work with an
|
|
|
|
|
unknown build of `jj` by having the tool run something like `jj api` to give it
|
|
|
|
|
an address to talk to.
|
|
|
|
|
|
|
|
|
|
In addition to helping with the problem of unknown backends, having an RPC API
|
|
|
|
|
should make it easier for tools like VS Code that are not written in Rust. The
|
|
|
|
|
RPC API will probably be at a higher abstraction level than the Rust API.
|
|
|
|
|
|
|
|
|
|
See [design doc][api-design-doc].
|
|
|
|
|
|
|
|
|
|
## Open-source cloud-based repos (server and daemon process)
|
|
|
|
|
|
|
|
|
|
Google has an internal Jujutsu server backed by a database. This server allows
|
|
|
|
|
commits and repos (operation logs) to be stored in the cloud (i.e. the database).
|
|
|
|
|
Working copies can still be stored locally.
|
|
|
|
|
|
|
|
|
|
In order to reduce latency, there is a local daemon process that caches reads
|
2024-09-04 17:38:24 +00:00
|
|
|
and writes. It also prefetches of objects it thinks the client might ask for
|
2024-08-19 05:58:10 +00:00
|
|
|
next. In also helps with write latency by optimistically answering write
|
|
|
|
|
requests (it therefore needs to know the server's hashing scheme so it can
|
|
|
|
|
return the right IDs).
|
|
|
|
|
|
|
|
|
|
We (the project, not necessarily Google) want to provide a similar experience
|
|
|
|
|
for all users. We would therefore like to create a similar server and daemon.
|
|
|
|
|
The daemon might be the same process as for the RPC API mentioned above.
|
|
|
|
|
|
|
|
|
|
## Virtual file system (VFS)
|
|
|
|
|
|
|
|
|
|
For very large projects and/or large files, it can be expensive to update the
|
|
|
|
|
working copy. We want to provide a VFS to help with that. Updating the working
|
|
|
|
|
copy to another commit can then be done simply by telling the VFS to use the
|
|
|
|
|
other commit as base, without needing to download any large files in the target
|
|
|
|
|
commit until the user asks for them via the file system. A VFS can also make it
|
|
|
|
|
cheap to snapshot the working copy by keeping track of all changes compared to
|
|
|
|
|
the base commit.
|
|
|
|
|
|
|
|
|
|
Having a VFS can also be very benefial for [`jj run`][jj-run], since we can then
|
|
|
|
|
cheaply create temporary working copies for the commands to run in.
|
|
|
|
|
|
|
|
|
|
## Better support for large files
|
|
|
|
|
|
|
|
|
|
We have talked about somehow using content-defined chunking (CDC) to reduce
|
|
|
|
|
storage and transfer costs for large files. Maybe we will store files in our
|
|
|
|
|
future cloud-based server using the same model as [XetHub][xet-storage].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[api-design-doc]: https://docs.google.com/document/d/1rOKvutee5TVYpFhh_UDNZDxfUKyrJ8rjCNpFaNHOHwU/edit?usp=sharing&resourcekey=0-922ApyoAjuXN_uTKqmCqjg
|
|
|
|
|
[copy-design-doc]: design/copy-tracking.md
|
|
|
|
|
[gg]: https://github.com/gulbanana/gg
|
|
|
|
|
[jj-run]: https://github.com/martinvonz/jj/issues/1869
|
|
|
|
|
[submodules]: https://github.com/martinvonz/jj/issues/494
|
|
|
|
|
[xet-storage]: https://xethub.com/assets/docs/concepts/xet-storage
|
