Feature: Implement Version Hash Check

[hecon5]

trafficstars

Currently, a full export is only forced upon a discrete version update. While testing out a bug fix for one of the latest PRs, I realized one of the things which were making testing difficult is I didn't update the version number while doing incremental testing, so a full export didn't occur. While this didn't end up being an issue, I thought it might be good to add a hash check value to the VCS.

This would allow for a self-check of the code to determine if it matches, and would make it so that while versions are displayed, a different discrete version would force an export.

To that end, I thought we've already fleshed out most of this with vcs-index. Because build dates don't effectively change the code, I think a way to do this would be to build a hash based on the index hashes of objects in the database. This hash value could be stored and self-computed upon install (or build), (perform an export to a temp directory, get the hash values, store the hash as a DB property, perhaps even as a , then destroy the temp directory).

• Hash is based on the concatenation of vcs-index hash values, not dates or other details. Only hash values of the built code (not the repository file hashes, only the hash values of the code and components within the built database).
• Hash value would be stored upon build
  • Users who install the db do not need to recompute this hash value and could compare to the deployed release to validate file match.
• Users could self compute before install (some properties, such as the dbs-Properties.AccessVersion and dbs-references` will change based on installed environment).
  • This would be applicable to folks who self-build based on the repo.

In addition to the distinct version number and options hash, the self-check hash would force a full export, as well.