2013/11/1 Richard Hipp <[email protected]>: > I have followed the discussion only casually and have not gone into too much > detail. But it does seem to me that there are in fact many "cases" here. > As a QA exercise, I wonder if someone could list all of the "cases" together > with a terse description of how Fossil should handle each case. Such a list > would be enormously helpful (it seems to me) in testing and determining that > the changes are really ready to merge.
What I basically would expect (without looking at the current/pending-review implementation): fossil clone [--once] http://[email protected] fossil sync [--once] http://[email protected] fossil pull [--once] http://[email protected] fossil push [--once] http://[email protected] 1) If a password is necessary and there is a saved password, use the saved password. 2) Otherwise, prompt for a password. 3) Do the actual clone/sync/.... 4) If the clone/sync/... did not succeed because of an authentication problem, go to step 2). Only repeat this a certain number of times. 5) If the clone/sync/... succeeded and a password was used which is different from the saved password, and no --once option is given, prompt whether the password should be saved. fossil clone [--once] http://user:[email protected] fossil sync [--once] http://user:[email protected] fossil pull [--once] http://user:[email protected] fossil push [--once] http://user:[email protected] 3) Do the actual clone/sync/.... using the supplied user:passwd 4) If the clone/sync/... did not succeed because of an authentication problem, go to step 2). Only repeat this a certain number of times. 5) If the clone/sync succeeded and a password was used which is different from the saved password, and no --once option is given, prompt whether the password should be saved. fossil update - Do a "fossil pull", but without prompting. Use the saved url/password, and if that doesn't work give up immediately. I think this would give the least number of unnecessary prompts. Currently, the password is saved before doing the clone/sync/... , but I think it should only be saved afterwards when the operation succeeds: If it fails the user should be given a chance to correct the password. And if the operation is aborted, the previously saved password should still be there. Something like this? Regards, Jan Nijtmans _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
