Changes to ticket 83af1f5401
By drh on 2008-10-18 13:34:09. See also: artifact content, and ticket history
- Appended to comment:
drh added on 2008-10-18 13:34:09:
A "fossil rollback" command is problematic, for two reasons.The first and less serious reason is that removing information from a fossil repository goes against the fossil philosophy of preserving all changes. There are other mechanisms in place to remove content from a fossil repository (ex: the "shun" mechanism) but these things are intended to combat spam. We have concerns about users routinely backing out their changes.
The second problem is that the rollback can only occur on the local repository. If a sync has occurred since the commit, then the commit has already been replicated onto other repositories. The next time the local repository syncs, the commit will reappear from the remote repository and the rollback will be undone. Note also that the default behavior is for the local repository to sync automatically after each commit, so there is a strong change that a sync will have occurred in between the commit and the rollback.
What exactly is the OP hoping to accomplish with a "rollback" command in fossil? There are two opportunities during the commit process to abandon the commit - while editing the check-in command and while entering the GPG password - so it seems unlikely that a commit might occur by accident. What problem would the "rollback" command solve?
- Change priority to "Immediate"
- Change private_contact to "da39a3ee5e6b4b0d3255bfef95601890afd80709"
- Change resolution to "Open"
- Change subsystem to "one"