#5496 Git browse view stalls on "Loading commit details ..."
The Leaf project reports that the commit browser for their https://sourceforge.net/p/leaf/bering-uclibc/commit_browser repository frequently stalls at "Loading commit details ..." which then never loads.
Several team members report this behavior.
Frequently the AJAX call returns fine, but sometimes it fails after timing out at 30 seconds.
Ref: [allura:tickets:#4304]
Another repo that consistently times out on the commit_browser: https://sourceforge.net/p/brlcad/code/commit_browser
On branch
db/5496, it is changed to be paginated.To test, find or create a git/hg repo that is pretty interesting in terms of branches being forked & merged. I cloned a repo with
git clone --mirror git://git.code.sf.net/p/xetex/codeand moved that into/git/p/myproj/newrepo.git/. Don't use the "xetex" though, find something different for better testing. Then do a repo refresh on it.Make sure the "Browse Commit" page works nice and fast and correctly. Compare the visual graph to the previous logic, and the parent/child commits labelled on each commit (after you click for details)
Make sure SVN stuff works still too, since I changed some
loglimitparams around.Known issue but should be rare: if you set pagination real low (
limitparam incommit_browser.jsyou can force this to be more likely) then the ordering of commits ends up coming through differently (due to how git fetches the commits, and the topo_sort server-side) as you load many pages vs lots in one page. This can cause a problem when a parent commit is assigned a column, but the parent commit doesn't arrive until much later do to the paging/sorting, and by then a different commit/branch has taken that column, so they end up sharing a column which is not correct. With a large pagination size, this should be fairly rare, since its only a problem when parent/child commits split a pagination break and have sufficient other commits in between due to sorting.Good improvement; clear to merge IMO.
Thanks!