Re: [fossil-users] Semi-Bug: File Browser in the web GUI is Relatively slow

2017-05-27 Thread Gour
On Fri, 26 May 2017 19:28:31 -0400
Richard Hipp  wrote:

> 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

2017-05-27 Thread Stephan Beal
On Fri, May 26, 2017 at 11:03 PM, Richard Hipp  wrote:

> 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

2017-05-26 Thread Richard Hipp
On 5/26/17, Richard Hipp  wrote:
>
> 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

2017-05-26 Thread Richard Hipp
On 5/26/17, Martin Vahi  wrote:
>
> 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

2017-05-26 Thread Martin Vahi

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