You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now revisions are identified by two checkout fields: git_commit_hash and patchset_hash. However, this gets cumbersome once we need to refer to them more often. E.g. like in the upcoming "transitions".
This will especially be a problem if we ever get a DAG database with revision connectivity information. In the current plans the node key is supposed to be a hash, and we don't have one right now for revisions.
So we need to come up with one. Perhaps we should add another required field to checkouts: revision_hash and define it as e.g. a hash over git_commit_hash followed by patch file hashes in order of application. Or rather, to be able to migrate the existing data, we might need to do a hash over git_commit_hash and patchset_hash.
The text was updated successfully, but these errors were encountered:
Right now revisions are identified by two checkout fields:
git_commit_hash
andpatchset_hash
. However, this gets cumbersome once we need to refer to them more often. E.g. like in the upcoming "transitions".This will especially be a problem if we ever get a DAG database with revision connectivity information. In the current plans the node key is supposed to be a hash, and we don't have one right now for revisions.
So we need to come up with one. Perhaps we should add another required field to checkouts:
revision_hash
and define it as e.g. a hash overgit_commit_hash
followed by patch file hashes in order of application. Or rather, to be able to migrate the existing data, we might need to do a hash overgit_commit_hash
andpatchset_hash
.The text was updated successfully, but these errors were encountered: