If a server has dropped the history that a client requests, the
server can return a 410 GONE response, to tell the client "sorry, I
don't have the history necessary to synchronize with you."
But if the server really dropped the history, then how would it know if the parent 1234567 a client is referring to is really 'gone' or maybe this version ID never was a part of this DAG to begin with?
I think the idea of Braid is that updates and merges never fail, right? So the merge algorithm should guarantee this? That does make it a lot easier than git push, which might for instance result in 'push rejected, please pull and rebase and try again'.
But even then, I could think of a number of useful versioning-related error codes, such as 'version not found', 'parent not found', 'merge algorithm not supported', 'merge failed'.
Section 3.5 says:
But if the server really dropped the history, then how would it know if the parent
1234567a client is referring to is really 'gone' or maybe this version ID never was a part of this DAG to begin with?I think the idea of Braid is that updates and merges never fail, right? So the merge algorithm should guarantee this? That does make it a lot easier than
git push, which might for instance result in 'push rejected, please pull and rebase and try again'.But even then, I could think of a number of useful versioning-related error codes, such as 'version not found', 'parent not found', 'merge algorithm not supported', 'merge failed'.