sqitch-rework - Rework a database change
sqitch [options] rework [<dependency-options>] name
This command allows for the reworking of an existing database change. It is best used only under the following circumstances:
There are production deployments, so that you cannot revert to before the change, modify it, and then re-deploy. Just reverting, modifying, and re-deploying is the thing to do while developing the database, but once it has been released and deployed to production, you must not change previous change scripts.
The modifications will be idempotent. In other words, either the earlier instance of the change or the new, reworked instance can be run any number of times, and the outcome of each will be the same. They must not break each other in case one needs to deploy and revert changes.
A tag must have been applied to the plan since the previous instance of the change. This is required so that Sqitch can disambiguate the two instances of the change. It's a good idea to always tag a release anyway. If you haven't, see sqitch-tag.
If all of these hold, then feel free to rework an existing change.
In effect, reworking a change is similar to adding one. However, rather than writing new files for the change, the
rework command copies the files for the existing change. The new files are named with the tag that comes between the changes, and serves as the file for the original change. This leaves you free to edit the existing files.
Name of a change that is required by the new change. May be specified multiple times. See sqitchchanges for the various ways in which change targets can be specified.
Name of a change that conflicts with the new change. May be specified multiple times. See sqitchchanges for the various ways in which change targets can be specified.
A brief note describing the purpose of the reworking. The note will be attached to the change as a comment. Multiple invocations will be concatenated together as separate paragraphs.
Part of the sqitch suite.