Hi Karel, I have quite a big repository (3.4G) imported from svn by a custom tool. It also took several minutes to commit, and most of the time was spent in md5 hash computation. It is extra precaution to ensure checkout file integrity, which can be turned off with repo-cksum setting.
With that setting off, it takes 4 to 6 second to commit. My hardware is ext4 on Samsung 850 Pro 512 SSD, i7-3770 Nikita On Fri, Oct 28, 2016, 10:03 Warren Young <[email protected]> wrote: > On Oct 28, 2016, at 3:45 AM, Karel Gardas <[email protected]> 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? > > Has anyone done something like produce a SLOC histogram for all projects > on GitHub or Sourceforge, so that we can say something like, “SQLite is in > the top 2nd percentile for open source C projects based on SLOCCount’s line > counting algorithm”? > > I’m intrigued enough to want to do the project, but I don’t think I really > want to clone the entirety of GitHub onto my HDD in order to find out, even > if it’s just one project at a time. That sounds like a great way to blow > through my Comcast data cap. > > > Let's talk about some real numbers to illustrate the situation. > > Yes, let’s. :) > > > $ 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? > > If you compare to the checkout time from NetBSD’s main CVS repository, you > aren’t comparing apples to oranges, since you’re transferring only the tip > of the trunk. You have to go back to the CVS server for any history. I > suspect if you checked out each CVS revision one at a time, it would take a > lot longer than pulling the whole project history with Fossil. > > If you want to compare with some other DVCS, post those numbers. > > > 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? > > Rebuilding is strictly optional. It just makes Fossil operations run > faster post-clone. > > Also realize that cloning is a one-time activity per development machine, > for anyone active enough in the project to maintain their local clone. > > A cute option would be if --skip-rebuild would look for a local at(1) > command, then offer to schedule the rebuild for a later time, after you’ve > left off work for the day. > > Although there may be casual clients who clone, do something with the > source, throw the clone repo away when done, then clone again a year later > when they need the source again, we should not optimize Fossil for that > case. > > 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. > > > - 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. > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
