On Fri, Oct 28, 2016 at 7:02 PM, Warren Young <w...@etr-usa.com> wrote: > On Oct 28, 2016, at 3:45 AM, Karel Gardas <gard...@gmail.com> wrote: >> >> make it more scale-able and allow its real usage also for projects of >> bigger size. > > How many projects are there bigger than SQLite, percentage-wise?
And does it really matter? The question was just question, anybody working scaling fossil better? I've though fossil is just another open-source DVCS where people are free to hack their ideas at least to test some new directions. >> $ time /opt/fossil-head/bin/fossil clone >> http://netbsd.sonnenberger.org/ netbsd-src.fossil >> >> It takes: >> >> real 323m2.323s >> user 42m0.262s >> sys 13m18.003s > > Okay, but compared to what? For example Git, on the same source tree: $ time git clone https://github.com/jsonn/src.git Cloning into 'src'... remote: Counting objects: 3725278, done. remote: Compressing objects: 100% (111/111), done. remote: Total 3725278 (delta 52), reused 0 (delta 0), pack-reused 3725166 Receiving objects: 100% (3725278/3725278), 2.18 GiB | 773.00 KiB/s, done. Resolving deltas: 100% (2782525/2782525), done. Checking connectivity... done. Checking out files: 100% (176388/176388), done. real 55m20.926s user 9m30.362s sys 4m50.320s >> rebuild alone >> takes around 250 minutes on the same hardware and with the same >> fossil. > > Would a --skip-rebuild option for fossil clone solve your major problem, then? There is no such option in current fossil. Some commands (import) supports --no-rebuild, but clone is not among them. > Rebuilding is strictly optional. It just makes Fossil operations run faster > post-clone. That's news to me, I've thought rebuild is strictly necessary to have other fossil commands working if not, hmm, allowing rebuild over night may be indeed an option. > We’ve already discussed shallow clones, which would make Fossil more like CVS > in terms of clone size. See the “Fossil 2.0” document Mr. Boogie linked to. Indeed, I've seen this, very appreciated. But originally I've thought in a line of kind of better optimization of rebuild implementation in current fossil without a need to go for future fossil version. I've been tempted to think into this direction by seeing excess amount of data fossil writes on rebuild and resulting repo size. > >> - commit, this is a little bit harder. One file modified and commit takes: >> real 4m0.765s >> user 1m55.442s >> sys 1m11.892s > > That seems like a much more important problem to solve. 4 minutes per commit > is simply *painful*, and it may happen multiple times per day, rather than > once per development box. > > Here, I occasionally see commit times of 10 seconds or so, and that’s painful > enough already. repo chksuming switching off as suggested by Nikita Borodikhin helps here a lot. The question is if to leave it to file-system or to fossil itself. Thanks, Karel _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
