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
