On Sat, Feb 25, 2012 at 2:26 AM, Gour <g...@atmarama.net> wrote: > Right. I'd like to have simple 'rollback' as well in a situation when I > quickly find out that the commit was simply mistake... >
A key philosophical design principle of Fossil is "no erasures". This is how business financial accounting is (or used to be) done. You write in ink. If an error is found, you annotate the erroneous entry with a note of correction and/or create new entries to undo the mistake. You do not erase or alter existing entries. And in this way one maintains an audit trail. Other VCSes allow you to edit the DAG. (The rebase command of git is the prime example.) That's OK for git because their philosophy is that the DAG is part of the project documentation and should be clean and neat. The Fossil philosophy, in contrast, is that the DAG should be a true and accurate history what you really did, rather than what you should have done. So the git-way of handling a mistaken commit would be to roll it back. The Fossil-way would be to tag that commit as being the beginning of a new branch, typically a branch named "mistake", and then close the branch. You can see examples of the Fossil-way, here: http://www.fossil-scm.org/fossil/timeline?c=2011-06-16+18%3A10%3A54&n=6 http://www.sqlite.org/src/timeline?r=mistake That said, I'm not completely opposed to having the ability to back out a mistaken commit, so long as that commit has not been pushed or synced to other repositories. It is DAG editing (rewriting history) that I am opposed to. Rewriting history (rebase) and omitting parts of history (rolling back commits) are distinct concepts, and rewriting (lying) is clearly a greater sin than omitting irrelevancies. But most Fossil users operate in autocommit mode, meaning that commit and push happen together, so there is seldom exist any unsynced commits, which is perhaps the biggest reason why rollback has never been implemented. For contributing to Fossil itself, there is a Pre-checkin Checklist<http://www.fossil-scm.org/fossil/doc/trunk/www/checkin.wiki>that developers are suppose to follow prior to each 'fossil commit". (A similar checklist exists for SQLite.) A key element of this checklist is the "fossil diff" - to make sure you really know what you are about to check in. Very often I spot debugging statements that should have been removed, missing or erroneous comments, bad indentation, or goofy variable names during that "fossil diff" step, and thus have an opportunity to correct those errors prior to making them a part of the permanent record. I also find that I am able to write better checkin comments if I have just reviewed all changes associated with the checkin. I highly recommend that you adopt some kind of short, simple pre-checkin checklist for your projects as well, and that this checklist involve a "diff" of what is about to be checked in. It really does help. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
