mirror of
https://github.com/martinvonz/jj.git
synced 2024-11-14 02:07:22 +03:00
9e1869dcef
`WorkingCopy::check_out()` currently fails if the commit recorded on
disk has changed since it was last read. It fails with a "concurrent
checkout" error. That usually works well in practice, but one can
imagine cases where it's not correct. For an example where the current
behavior is wrong, consider this sequence of events:
1. Process A loads the repo and working copy.
2. Process B loads the repo at operation A. It has not loaded the
working copy yet.
3. Process A writes an operation and updates the working copy.
4. Process B loads the working copy and sees that it is checked out
to the commit process B set it to. We don't currently have any
checks that the working copy commit matches the view's checkout
(though I plan to add that).
5. Process B finishes its operation (which is now divergent with the
operation written by process A). It updates the working copy to
the checkout set in the repo view by process B. There's no data
loss here, but the behavior is surprising because we would usually
tell the user that we detected a concurrent update to the working
copy.
We should instead check that the working copy's commit on disk matches
what the previous repo view said, i.e. the view at the start of the
operation we just committed. This patch does that by having the caller
pass in the expected old commit ID.
|
||
|---|---|---|
| .. | ||
| test_bad_locking.rs | ||
| test_commit_builder.rs | ||
| test_commit_concurrent.rs | ||
| test_conflicts.rs | ||
| test_diff_summary.rs | ||
| test_git.rs | ||
| test_index.rs | ||
| test_init.rs | ||
| test_load_repo.rs | ||
| test_merge_trees.rs | ||
| test_mut_repo.rs | ||
| test_operations.rs | ||
| test_refs.rs | ||
| test_revset_graph_iterator.rs | ||
| test_revset.rs | ||
| test_rewrite.rs | ||
| test_view.rs | ||
| test_working_copy_concurrent.rs | ||
| test_working_copy.rs | ||
| test_workspace.rs | ||