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

docs: some futher touch-ups of concurrency.md

Browse source
This commit is contained in:
Martin von Zweigbergk 2022-01-12 23:08:53 -08:00
parent 8a0afc3016
commit 4e20548e32
1 changed files with 14 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
docs/technical/concurrency.md
View file

@ -25,7 +25,7 @@ frequently get corrupted, for example).
Another problem with using lock files is related to complexity of
implementation. The simplest way of using lock files is to take coarse-grained
early: every command that may modify the repo takes a lock at the very
locks early: every command that may modify the repo takes a lock at the very
beginning. However, that means that operations that wouldn't actually conflict
would still have to wait for each other. The user experience can be improved by
using finer-grained locks and/or taking the locks later. The drawback of that is
@ -35,7 +35,7 @@ locking are still valid.
To avoid depending on lock files, Jujutsu takes a different approach by
accepting that concurrent changes can always happen. It instead exposes any
conflicting changes to the user, much like other DVCSs do for conflicting
changes done remotely.
changes made remotely.
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.)
@ -74,12 +74,12 @@ view of the repo and are guaranteed to be able to commit their changes --
greatly simplifies the implementation of commands.
It is possible to load the repo at a particular operation with
`jj --at-operation <command>`. If the command is mutational, that will result
in a fork in the operation log. That works exactly the same as if any later
operations had not existed when the command started. In other words, running
commands on a repo loaded at an earlier operation works the same way as if the
operations had been concurrent. This can be useful for simulating concurrent
operations.
`jj --at-operation=<operation ID> <command>`. If the command is mutational, that
will result in a fork in the operation log. That works exactly the same as if
any later operations had not existed when the command started. In other words,
running commands on a repo loaded at an earlier operation works the same way as
if the operations had been concurrent. This can be useful for simulating
concurrent operations.
### Merging concurrent operations
@ -87,16 +87,16 @@ If Jujutsu tries to load the repo and finds multiple heads in the operation log,
it will do a 3-way merge of the view objects based on their common ancestor
(possibly several 3-way merges if there were more than two heads). Conflicts
are recorded in the resulting view object. For example, if branch `main` was
moved from commit A to commit B in one operation and moved to commit C in
moved from commit A to commit B in one operation and moved to commit C in a
concurrent operation, then `main` will be recorded as "moved from A to B or C".
See the `RefTarget` [definition](../../lib/protos/op_store.proto).
Because we allow branches (etc.) to be in a conflicted state rather than just
erroring out when there are multiple heads, the user continue to use the repo,
including performing further operations on the repo. Of course, some commands
will fail when using a conflicted branch. For example, `jj checkout main` when
`main` is in a conflicted state will result in an error telling you that `main`
resolved to multiple revisions.
erroring out when there are multiple heads, the user can continue to use the
repo, including performing further operations on the repo. Of course, some
commands will fail when using a conflicted branch. For example,
`jj checkout main` when `main` is in a conflicted state will result in an error
telling you that `main` resolved to multiple revisions.
### Storage