Fossil

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?

anonymous claiming to be lRem added on 2009-04-08 15:45:30:
I second this feature request. It happens from time to time that a bad commit happens. The line

# EDITED   some_file

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:
If, as you say, you accidently check in a file that contains your CC numbers, you can use the "Shun" mechanism to remove that file from the repository, and to prevent it from being added again in the future (for example due to a sync.)

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:
Perhaps call it "fossil rewind" to "unplay" the commits, up to a certain point? I.e. if "fossil timeline" initially displays something like this:

• [beddable] checkin of big fix
• [deadbeef] code change xyz...
• [cafebabe] update code for new password changes...
• [debac1e5] Closed ticket xyz...
• [f005ba11] correct feature A as per ticket debac1e5...
• [decaf000] update supporting libabc to version 2...

"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:

• [c0ffee55] Rewind: (to [debac1e5]) password accidentally checked-in with code
• [debac1e5] Closed ticket xyz...
• [f005ba11] correct feature A as per ticket debac1e5...
• [decaf000] update supporting libabc to version 2...

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

• [be55077d] Replay: end of replay [ca5caded]
• [ace55ab1] checkin of big fix
• [defaced1] code change xyz
• [ca5caded] Replay: start
• [1dec0ded] password changes in code, but didn't commit actual password this time
• [c0ffee55] Rewind: (to [debac1e5]) password accidentally checked-in with code
• [debac1e5] Closed ticket xyz...
• [f005ba11] correct feature A as per ticket debac1e5...
• [decaf000] update supporting libabc to version 2...

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:
If this discussion continues, it should be moved to a rewinding wiki page...

anonymous claiming to be lRem added on 2009-04-08 19:37:56:
Ok, I've missed the shun feature. It's all that I need in this matter.