On Tue, Jul 16, 2013 at 03:17:10PM +0200, Stephan Beal wrote: > On Tue, Jul 16, 2013 at 2:51 PM, Joerg Sonnenberger <jo...@britannica.bec.de > > wrote: > > > Just a matter of scale :) Essentially, the problem is that t(fossil > > update) = O(files in the working copy), when it should be O(files > > changed). > > > > Just out of curiosity - is this with the mtime-changes setting enabled or > disabled?
Enabled. > It seems to me (perhaps naively) that fossil must first understand what has > changed, which means (at least in principal) checking all current entries > in the repo, so i would expect O(N), N==number of files in current branch > (or thereabouts). No, it builds a change list by comparing old and new manifest. That part is fast. The problem is that it is completely rewriting the table after that. Joerg _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
