Re: [fossil-users] Semi-Bug: File Browser in the web GUI is Relatively slow
On Fri, 26 May 2017 19:28:31 -0400 Richard Hippwrote: > On the other hand, I also made some good design choices, such as the > use of SQLite for storage. And it occurred to me at dinner that I can > modify the query used to generate the file list page to work around > this problem, and make it fast. I'll see if I can work on that > tonight... Does that make the need for Fit obsolete or Fit can be made using SQLite for storage? Sincerely, Gour -- The senses, the mind and the intelligence are the sitting places of this lust. Through them lust covers the real knowledge of the living entity and bewilders him. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Semi-Bug: File Browser in the web GUI is Relatively slow
On Fri, May 26, 2017 at 11:03 PM, Richard Hippwrote: > I've been kicking around a new idea lately: "Fit" which is a > combination of "Fossil" and "Git". Basically, it uses Git's > hierarchical low-level file structure artifact format but with > Fossil's UI and implementation. Such a design would scale better to > projects with many hundreds of thousands of files. And it would be > able to push and pull with legacy Git clients for collaboration. All > the while retaining the ease of use, rich interface, and module design > that most people like about Fossil. > Apropos... this popped up in the news: https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/ Says: >>> As a refresher, the Windows code base is approximately 3.5M files and, when checked in to a Git repo, results in a repo of about 300GB. Further, the Windows team is about 4,000 engineers and the engineering system produces 1,760 daily “lab builds” across 440 branches in addition to thousands of pull request validation builds. All 3 of the dimensions (file count, repo size and activity), independently, provide daunting scaling challenges and taken together they make it unbelievably challenging to create a great experience. Before the move to Git, in Source Depot, it was spread across 40+ depots and we had a tool to manage operations that spanned them. <<< -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Semi-Bug: File Browser in the web GUI is Relatively slow
On 5/26/17, Richard Hippwrote: > > Sadly, I made some design decisions early on that make it difficult to > scale Fossil to these kinds of massive projects. > On the other hand, I also made some good design choices, such as the use of SQLite for storage. And it occurred to me at dinner that I can modify the query used to generate the file list page to work around this problem, and make it fast. I'll see if I can work on that tonight... -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Semi-Bug: File Browser in the web GUI is Relatively slow
On 5/26/17, Martin Vahiwrote: > > 3) > While being at the "Home" or "Wiki" page, > select the "Files" menu option and observe > the multi-second delay. Navigating folders > at the Web based file browser is also > slightly sluggish. That's because you have 403,890 separate files in your project. By comparison, SQLite (the project for which Fossil was designed) has 1,945 files and Fossil itself has only 1,007 files. NetBSD, which is what most people think of when you say "big project with a lot of files", has only 307,454. Sadly, I made some design decisions early on that make it difficult to scale Fossil to these kinds of massive projects. I've been kicking around a new idea lately: "Fit" which is a combination of "Fossil" and "Git". Basically, it uses Git's hierarchical low-level file structure artifact format but with Fossil's UI and implementation. Such a design would scale better to projects with many hundreds of thousands of files. And it would be able to push and pull with legacy Git clients for collaboration. All the while retaining the ease of use, rich interface, and module design that most people like about Fossil. A key design requirement for "Fit" is that when you import from Fossil, it remembers all of the legacy Fossil hash identifiers and uses those as aliases for the new Fit/Git hashes, so that references to Fossil hash names continue to work. Also, the Git file structure would need to be extended to support tickets and wiki and named branches and a few other details like that, but all of that should be easy to do. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Semi-Bug: File Browser in the web GUI is Relatively slow
Reproduction: 1) Open the link behind the "Home" menu option, the page page at https://www.softf1.com/cgi-bin/tree1/technology/flaws/mmmv_parasail_projects.bash/home 2) Select the "Wiki" menu option and observe that the site is "lightning fast", the new page is displayed practically the moment the finger comes back up at the mouse button. The same holds, when web browser cache is emptied while stying at the "Home" page and then moving to the "Wiki" page. On google Crhome: Ctrl-Shift-Del 3) While being at the "Home" or "Wiki" page, select the "Files" menu option and observe the multi-second delay. Navigating folders at the Web based file browser is also slightly sluggish. Thank You for reading my letter. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users