mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-12-27 06:27:43 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: More info about syncing jj repo with rsync

Browse source 
This will be used for context in the next commit

Includes a mention of
https://github.com/martinvonz/jj/issues/2193.
This commit is contained in:
Ilya Grigoriev 2023-04-16 21:30:36 -07:00
parent 7c8f66ab0c
commit be8be2e55a
1 changed files with 16 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docs/technical/concurrency.md
View file

@ -37,6 +37,8 @@ accepting that concurrent changes can always happen. It instead exposes any
conflicting changes to the user, much like other DVCSs do for conflicting conflicting changes to the user, much like other DVCSs do for conflicting
changes made remotely. changes made remotely.
### Syncing with `rsync`, NFS, Dropbox, etc
Jujutsu's lock-free concurrency means that it's possible to update copies of the Jujutsu's lock-free concurrency means that it's possible to update copies of the
clone on different machines and then let `rsync` (or Dropbox, or NFS, etc.) clone on different machines and then let `rsync` (or Dropbox, or NFS, etc.)
merge them. The working copy may mismatch what's supposed to be checked out, but merge them. The working copy may mismatch what's supposed to be checked out, but
@ -46,12 +48,24 @@ branch was moved to two different locations, they will appear in `jj log` in
both locations but with a "?" after the name, and `jj status` will also inform both locations but with a "?" after the name, and `jj status` will also inform
the user about the conflict. the user about the conflict.
The most important piece in the lock-free design is the "operation log". That is Note that, for now, there are known bugs in this area. Most notably, with the
what allows us to detect and merge concurrent operations. Git backend, [repository corruption is possible because the backend is not
entirely lock-free](https://github.com/martinvonz/jj/issues/2193). If you know
about the bug, it is relatively easy to recover from.
Moreover, such use of Jujutsu is not currently thoroughly tested,
especially in the context of [co-located
repositories](../glossary.md#co-located-repos). While the contents of commits
should be safe, concurrent modification of a repository from different computers
might conceivably lose some branch pointers. Note that, unlike in pure
Git, losing a branch pointer does not lead to losing commits.
## Operation log ## Operation log
The most important piece in the lock-free design is the "operation log". That is
what allows us to detect and merge concurrent operations.
The operation log is similar to a commit DAG (such as in The operation log is similar to a commit DAG (such as in
[Git's object model](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)), [Git's object model](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)),
but each commit object is instead an "operation" and each tree object is instead but each commit object is instead an "operation" and each tree object is instead