Issue #31 and the fix in PR #32 revealed a gap in maintaining the immutability of the migration chain in a Git repository network. A more reliable process would be:
Merge (or directly commit) changes into the "main branch" (master or a version-specific branch)
Use the new xmigra promote tool to update the central definition of production (preceded by checks that the new commit is consistent with the old one).
Setting this up would involve using a branch name different than master in the xmigra-master Git attribute for the database.yaml file -- possibly something like prod-db-chain. It will probably also be necessary to mark a branch as the "premaster" to prevent accidentally promoting unmerged development changes to the database schema's master branch.
The git commit-tree command might be helpful to build a production migration chain branch that purely represents the sequence of trees promoted with this tool.
Issue #31 and the fix in PR #32 revealed a gap in maintaining the immutability of the migration chain in a Git repository network. A more reliable process would be:
master
or a version-specific branch)xmigra promote
tool to update the central definition of production (preceded by checks that the new commit is consistent with the old one).Setting this up would involve using a branch name different than
master
in thexmigra-master
Git attribute for thedatabase.yaml
file -- possibly something likeprod-db-chain
. It will probably also be necessary to mark a branch as the "premaster" to prevent accidentally promoting unmerged development changes to the database schema's master branch.