Comment by carterehsmith | Hacker News Reader

Comment by carterehsmith | Hacker News Reader

Parent Full thread

The fact that you created both an SCM, and a RDBMS, kind of forces the question:

Does Fossil have something like 'rollback'?

If not, would it not be good to have your standard SQL COMMIT/ROLLBACK semantics in an SCM?

I mean, sometimes you do something with your SCM that you immediately regret. Like, you do a 'pull' expecting that perhaps a couple files will be changed, and instead you get a screenful of statuses, errors and whatnots.

Ooops! So you look at what you typed, and turns out you were in a wrong branch, or you should have used 'pull x y' or whatever.

In any case, what you want to do now, is to 'roll back' ('undo') the last command.

Now, in SQL, when you make a mistake, you say 'rollback' and everything is good.

But in a typical SCM, either you cannot do it at all, or it is nontrivial. E.g. in Git, the way to 'undo' depends on the command that you are undoing. Sometimes it is 'revert', sometimes 'reset ^XX~xx' or 'abort', etc etc, clearly not optimal.

Is there an SCM that does that?

Fossil does have an undo command but that doesn't work on commits (checkin). It works on update and revert. Also thete is no rebase to edit the history. Once you commit it's there. You just mark the bad commit as a mistake or commit changes in the following checkin. Stuff never gets deleted from the repo but there is a scrub command. All of this encourages one to commit responsibly.

That's interesting an idea in Fossil that I've always assumed was borrowed from database ideology. When data is committed to a database and other data depends on it, deleting data risks damaging data integrity, let alone issues of falsifying the record.

Fossil enforces the ethical principle that history, e.g., of a project, should not be revised after the fact. If broken code is submitted to the repo, it can be replaced, the prior code ignored, but it still is part of the project history, perhaps serving as a reminder of how things can go wrong, often a valuable lesson to pass along.

Projects are like people, we all have warts. We don't have to point them out to casual acquaintances, but we shouldn't try to pretend we don't have them at all.

Sounds reasonable. Not being able to undo a checkin does not seem like a problem to me, as checkins don't usually bring about ooops moments, if ever.

Also, immutable history makes a lot of sense, not just for SCM, but for RDBMS, too.

So we see quite a few people are now going with the append-only databases.

> Does Fossil have something like 'rollback'?

Yes, but not like you mean. A commit is made using a SQLite transaction, so if any part of the commit process fails, it will roll the Fossil repo DB back to its prior state, preventing DB corruption. If you're synchronizing to a remote repository, a failure on the remote also rolls back changes to the local copy, too.

As for rolling back an already committed change, even DBMSes don't work like that. A Fossil commit is the same as SQL COMMIT: the transaction is committed now, and can't be backed out without a subsequent modification.

That said, a common way to get the effect you want with Fossil is to mark the bad commit as the start of a new branch, then resume work on the previously-damaged branch. Rather than delete history, this just pushes it off to the side, as a failed branch.

This does mean that if you make a bad commit, then make two more good commits on top of it, that moving the bad commit to an "ignored" branch will also move the two subsequent commits. However, Fossil also has a cherrypick feature that would let you apply the two good commits to the good branch.

You can sum Fossil vs Git up this way, in this regard: Git remembers what you should have done, Fossil remembers what you actually did.

> common way to get the effect you want with Fossil is to mark the bad commit as the start of a new branch, then resume work on the previously-damaged branch

Would it not be easier to just say "rollback"? Note that a "rollback" would apply just to the things changed since the last commit, just like in SQL. So then, by definition, you cannot rollback a commit. Just like in SQL.

> just like in SQL.

Which SQL dialect are you using where you can ROLLBACK after COMMIT? That isn't ANSI SQL-92 or SQLite behavior. Quoting the standard:

> An SQL-transaction is terminated by a <commit statement> or a <rollback statement>.

Perhaps you were thinking of savepoints?

`git reflog` almost always works. You can end up losing data when you have changes to untracked files and you do something like `git clean`.

Mercurial has a 'rollback' command, which they've marked as deprecated a few months (years?) ago, but you can still use it when you reach a tight spot.

Thanks, that's interesting.

Hmm, reading about it, it looks like Mercurial's rollback "can be dangerous". That's kind of opposite of what you expect rollback to be.

In a vcs it seems natural that rollback is dangerous - it should be the only way to delete work? The only alternative would be to stash what is rolled back in a branch, or somewhere else on disk? At witch point it isn't really a rollback anymore?

Aside from that, I think all major vcs will allow you to clone "up to revision N" which in turn will give you a new repository that has been rolled back to N?

Right, but I was talking specifically SQL-like semantics.

Whatever you comitted, you cannot rollback.

Or, say you have some unstaged changes, then accidentally issue a wrong pull or rebase or checkout, then rollback should affect just the pull/rebase/checkout, and get you back to where you had unstaged changes.

So there is no data loss in that scenario, as you can repeat the last command and get exactly the same result.

BTW I am not saying it cannot be done in a regular vcs, its just that it requires different command in different situations, and that obviously causes all kind of problems for many people.

Reply on news.ycombinator.com