Thus said Stephan Beal on Sun, 05 Oct 2014 18:41:33 +0200: > It still seems horribly inefficient, though, considering all the > db-level work it does there, knowing it's going to roll back the > transaction.
Actually, at the moment, there isn't much inefficiency because it's all local. fossil update --dry-run is local only operation. It doesn't involve any network sync operations. I agree, however, that if fossil update --dry-run did network sync operations and combined with a new -s option would introduce a different set of inefficiencies---mainly that it would necessarily mean downloading potentially large file artifacts, parsing the manifests, and all the requisite DB updates, simply to detect that there are changes and report. Unless the report is naive and simply reports if there are any unseen artifacts (halting the sync operation after it has received the unclustered artifacts list and then checking the blob table for them). On the other hand, the case of fossil update -s seems clear enough, just run the update and exit non-zero if no updates were made. > The question then becomes, "do we squelch error messages, too?" (And, > if "no," can we separate that output without more notable surgery. > Initial brief analysis suggests that it wouldn't be too much work.) If one wants to squelch error messages shouldn't one just redirect stderr to /dev/null? :-) Andy -- TAI64 timestamp: 400000005432262b _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
