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.
Right now revisions are identified by two checkout fields:
git_commit_hashandpatchset_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_hashand define it as e.g. a hash overgit_commit_hashfollowed 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_hashandpatchset_hash.