3 ms·

Regarding 2, why do you need the ability to distinguish these cases? After all, those two repositories are in the same state, which is that p is applied. The on

Regarding 2, why do you need the ability to distinguish these cases? After all, those two repositories are in the same state, which is that p is applied. The only reason you'd want to distinguish is if you want to preserve history. What about the distributed scenario makes it special?

dan-robertson 7y ago
Because a DVCS has to be distributed. If Alice writes patch p, Bob reverts it, and Charlie unreverts it, you might (without contexts) have three people with different states of the repo: Alice: {p} Bob: {p, !p} (or do you write this as {}?) Charlie: {p, !p, p} = {p, !p}? So I guess this has to be {p} Suppose these people are pushing and merge if in patches to the master. Then it has no way to distinguish these scenarios: A: 1. Alice pushes; master applies p 2. Bob pulls, reverts p, pushes. Master reverts p 3. Charlie pulls, reapplies, pushes. Master does ?? B 1. Alice pushes; master applies p 2. Charlie pulls 3. Bob pulls and reverts; master reverts p 4. Charlie pushes In both cases, the state of Charlie’s repo is the same: {p}, but in case A, p should be applied and in case B, it should not. Therefore there needs to be some additional context (or no applying a patch and it’s inverse). In other words, this problem is basically having a distributed set with addition, deletion, and readdition of elements, which you can’t have in a nice way. A distributed set that you can only add to, on the other hand, is a lot more easy.
- macintux 7y ago
  CRDTs have to tackle this sort of problem as well.
  - dan-robertson 7y ago
    Right. And a CRDT for a set you can add and remove from is either hard or weird for this reason. Also I think you don’t actually want your repo to be a CRDT because a CRDT resolves all conflicts and that would mean merge conflicts get resolved in an arbitrary way (leading to unexpected results and bad code). Maybe you could say that merge conflicts don’t count as conflicts in the CRDT sense of the word but that just feels like you’re abusing the notion of what a CRDT is.
    - afiori 7y ago
      I don't know how good of an idea CRDT would be here, but from the pijul perspective the CRDT layer should not possibly create a conflict, in the same way a `git fetch` should never cause a conflict (assuming well behaved hashes). The CRDT layer would produce a set of patches in an unmergeable state and then pijul would have to fix it; just like git.

dan-robertson 7y ago

Because a DVCS has to be distributed. If Alice writes patch p, Bob reverts it, and Charlie unreverts it, you might (without contexts) have three people with different states of the repo: Alice: {p} Bob: {p, !p} (or do you write this as {}?) Charlie: {p, !p, p} = {p, !p}? So I guess this has to be {p} Suppose these people are pushing and merge if in patches to the master. Then it has no way to distinguish these scenarios: A: 1. Alice pushes; master applies p 2. Bob pulls, reverts p, pushes. Master reverts p 3. Charlie pulls, reapplies, pushes. Master does ?? B 1. Alice pushes; master applies p 2. Charlie pulls 3. Bob pulls and reverts; master reverts p 4. Charlie pushes In both cases, the state of Charlie’s repo is the same: {p}, but in case A, p should be applied and in case B, it should not. Therefore there needs to be some additional context (or no applying a patch and it’s inverse). In other words, this problem is basically having a distributed set with addition, deletion, and readdition of elements, which you can’t have in a nice way. A distributed set that you can only add to, on the other hand, is a lot more easy.

macintux 7y ago
CRDTs have to tackle this sort of problem as well.
- dan-robertson 7y ago
  Right. And a CRDT for a set you can add and remove from is either hard or weird for this reason. Also I think you don’t actually want your repo to be a CRDT because a CRDT resolves all conflicts and that would mean merge conflicts get resolved in an arbitrary way (leading to unexpected results and bad code). Maybe you could say that merge conflicts don’t count as conflicts in the CRDT sense of the word but that just feels like you’re abusing the notion of what a CRDT is.
  - afiori 7y ago
    I don't know how good of an idea CRDT would be here, but from the pijul perspective the CRDT layer should not possibly create a conflict, in the same way a `git fetch` should never cause a conflict (assuming well behaved hashes). The CRDT layer would produce a set of patches in an unmergeable state and then pijul would have to fix it; just like git.