On Wed, Dec 9, 2009 at 10:29 PM, D. Richard Hipp <[email protected]> wrote:
> It seems to me that a better approach would be to improve the "commit" > command so that it does a better job of detecting problems *before* it > asks you to type in the commit message. In other words, if the commit > is going to fail, have it fail early. > The interesting thing about this is: if fossil can run at all then it has opened the repo (or does it not do that automatically at startup?). If it can open the repo, it basically cannot fail to commit unless the commit might fork (which it cannot know until it tries to commit). Only a moved repo (on Unix: to a different physical device), an offline network/USB drive, or a sudden "chmod -w" should cause a commit to fail. A "push", of course, can fail (and we don't lose anything), but the local commit should only fail in weird cases which signify a larger problem than a lost commit message. Checking for a potential commit-fork, then asking for the commit message, then committing would not suffice as a "pre-check" because there's a possibility of a separate commit hitting the repo between the message entry (presumably a long entry, from the OP's description) and the actual commit (i.e. the classic race condition). -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
