|Last Modified:||2015-02-17 00:55:53|
|Version Found In:|
|Description & Comments:|
`fossil rollback` - undo the commit but leave files modication
drh added on 2008-10-18 13:34:09:
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?
anonymous claiming to be lRem added on 2009-04-08 15:45:30:
# EDITED some_filedoes not prevent you from revealing your CC number you put there as a test string ;)
Now if I want to rollback a bad commit the only way to do it is to remove the local repository, pull and apply my changes once again. This is a lot of work that could be avoided. As you wrote nothing can be done about changes that were pushed somewhere. But that is acceptable - one has to look out for his own autosync...
drh added on 2009-04-08 16:22:34:
The Shun mechanism was created for this and related purposes: to remove wiki-spam or inappropriate or obscene comments or remarks or to remove copyrighted material or material that contains trade secrets.
Shunning can be done from the web UI. For some screens that show a single artifact, there is a "Shun" submenu option. (You have to have Admin privilege to see it, I think.) Or you can type in the SHA1 id of an artifact in the Shun screen which is found off of the main Admin page. Shunning takes effect the next time the repository is rebuilt.
bharder added on 2009-04-08 17:19:16:
"fossil rewind debac1e5 -m 'password accidentally checked-in with code'" would leave the repository in a state where ticket [debac1e5] is the last entry. The manifest would be rebuilt to reflect repo state. I'd hope that syncing the checked-out files would not be done automatically. From there, a user could "fossil commit" to commit current diffs again, or re-checkout whatever baseline they want reflected on disk...
As I think of it, perhaps a "rewind" entry could be installed as an artifact, too. So, after the above operation the "fossil timeline" might read:
I'm guessing, too, that the "rewind" entries would *absolutely* need to be immutable (ie: non-rewindable themselves).
...as I think about this more, it could also be nice to rewind artifacts to a temp storage, fix the point-in-time error (ie: take out the CC#, or password), then replay the temp storage back to the main repo... correctly only the mistake of entering a CC# or password, etc., but allowing the repo to otherwise easily be brought back to initial (pre-rewind) state. That's really breaking the "must not be mutable" philosophy of drh's though.
fossil rewind debac1e5 ;# rewinds main repo to "debac1e5", storing unwound items on temporary stack
[do local edits] ;# i.e.: remove the CC#
fossil commit ;# now there is no embedded CC#, or secret password
fossil replay deadbeef ;# replays stack taken with "fossil rewind", starting with deadbeef, to end (beddable)
fossil timeline ;# new state after rewind/edit/replay
I'm sure there are corner cases, and details to be worked-out, but it sounds interesting...
bharder added on 2009-04-08 17:24:24:
anonymous claiming to be lRem added on 2009-04-08 19:37:56: