On Oct 30, 2016, at 1:57 AM, Karel Gardas <gard...@gmail.com> wrote: > > 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?
Sure it does. Fossil is fast enough for SQLite, so if SQLite is “very large” compared to most other projects that could usefully use it, then speeding up Fossil amounts to spending effort on a tiny minority of users. All of that is predicated on that first “if,” however. >>> $ 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 So given your other report, that rebuild takes 250 minutes of that time, then Fossil is within about 25% of the speed of Git, if you don’t rebuild. >>> 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. I didn’t tell you to use that option, I asked if you would like that option to exist. >> 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 Nope. The only reason Fossil rebuilds by default is that the clone operation results in a sub-optimal DB, because each cloned artifact is checked into the new DB separately. You end up with a series of incremental states, none of which are equal to the final DB state once the clone is finished. Rebuilding forces the SQLite instance inside Fossil to take a new look at all the cloned artifacts as a whole and optimize the DB for that completed post-clone state, rather than the series of incremental states that exist at each point during the clone. > 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. If your filesystem has strong data checksumming (as opposed to just metadata checksumming) then I see no reason to leave repo-cksum turned on. Keep in mind that the vast majority of filesystems in common use do *not* have strong data checksumming, so letting repo-cksum default on is a good idea. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
