Possible race in git notes when using git backend #3
Comments
|
This race will get fixed by my work to replace Git notes by another format (#7). However, there's still a race that can happen: If the two machines write the same Git commit with different non-Git metadata (such as different change id), then they'll both succeed but the non-Git metadata will be taken from one of them. That's much less serious because it seems very unlikely to happen, and it's only the conflicting commit's metadata that gets lost. |
martinvonz
added a commit
that referenced
this issue
Oct 20, 2021
The new store works the same way as the `OpHeadsStore`. It keeps track of the current head file(s) by recording their names in a directory. When a write happens, it adds the new head and then removes the old head. There will be generally be a single head at a time. The only exception is when there's been concurrent operations (locally, or remotely, in the case of a distributed file system). When there are multiple heads files, they are automatically merged. No guarantee is given about which value wins if the key exists in several heads; the store is meant to be used for data that's immutable once written. As long as different keys are written, this is a CRDT. That makes it fit for solving both #3 and #7.
yuja
added a commit
to yuja/jj
that referenced
this issue
May 19, 2023
Since non-Git metadata isn't hashed, we can't rely on the consistency provided by content-addressed storage. The problem is also described in jj-vcs#3 (comment) jj-vcs#924
yuja
added a commit
to yuja/jj
that referenced
this issue
May 19, 2023
Since non-Git metadata isn't hashed, we can't rely on the consistency provided by content-addressed storage. The problem is also described in jj-vcs#3 (comment) jj-vcs#924
yuja
added a commit
that referenced
this issue
May 20, 2023
Since non-Git metadata isn't hashed, we can't rely on the consistency provided by content-addressed storage. The problem is also described in #3 (comment) #924
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Let's say there are two concurrent processes that add commits. They will both try to update the
refs/notes/jj/commits(and possiblyrefs/notes/jj/conflicts) git notes ref when using the git backend. We already retry when that happens, but that's not enough on file systems with poor locking. Perhaps we should record the notes refs and their target in the view object and then update the underlying git repo when resolving conflicts.The text was updated successfully, but these errors were encountered: