#2252 hgweb


Our project was migrated from the old to the new Sourceforge (SF). As a corollary, the default repository web view (hgweb) that comes with every decent default Mercurial (Hg) install is gone. Instead we get what I will call SFweb. In this analysis I will expose SFweb's shortcomings over hgweb and advocate for the re-activation of default hgweb to our project. In the alternative, I kindly ask you to fix the exposed shortcomings. If the status quo persists, I will instigate our project's migration to better suited alternative services from your competitors.

The purpose of a repository's web view is to (a) efficiently drill down; (b) visualize; and (c) share references (URL) to specific changesets in a repository along three dimensions: time (changesets), space (the codebase file layout) and the universe (the arboresence of spaces which include branches).

I contrast and compare SFweb and hgweb as of January 1, 2013 at the following URLs in relation to the above purpose.

SFweb: http://sourceforge.net/p/enblend/code/ci/67d11d6adebba021593c89b41ff8c68b2febc3a5/tree/

hgweb: http://hugin.hg.sourceforge.net/hgweb/hugin/

(a) NAVIGATION (drill down)

On the stock hgview, I am presented with a sequence of logical choices to drill down the tree I want to navigate. First I select the repository on http://hugin.hg.sourceforge.net/hgweb/hugin/ and then the universe on http://hugin.hg.sourceforge.net/hgweb/hugin/hugin. In two clicks I have locked in the first of the three dimensions. The two web pages present me with the most important information that drive my choice. The information is relevant and is presented in a visually efficient manner. The visual unit is a line (very important because a line is also the visual unit for any piece of code). The display is uncluttered and allows for a reasonable number of repositories and branches to be displayed on an average screen without the need for scrolling or other time wasting human intervention. On those two web pages I do not need to process unnecessary information to decide whether it is relevant or not to my choice; and I do not need to look for information that I am missing to make my choice.

In contrast, on SFweb, there is no visual unit. The display is cluttered with irrelevant information that slows me down as I need to discern the relevant from the irrelevant.

Repositories are represented by a large icon-with-text that has ZERO relevant information to help me choose which repository I want to drill down to. I am missing the most important information: last modified date. And then also who modified it. Visually repositories occupy 4x more vertical space. Horizontal space is wasted by the artificial limits of the layout design on a 1920px wide desktop display, is barely acceptable on a 1366px wide notebook display and is useless on a smaller display or when the web browser is windowed. To make things worse, the list of repositories is horizontal and mixed with other interface elements (admin/files/wiki/etc.) that at this point are irrelevant distractions. The space left for repositories is not enough and I do not want to imagine how you have solved the issue when a project has more repositories than the space alloted by the limiting layout.

Branches and Tags fare no better treatment. Visually they are confined by the layout rectangles on the left hand side of the layout. They occupy 3x more vertical space than in hgweb. Horizontally the space is so limited it can't even display properly the name of a branch. There is some number highlighted on each branch, its importance escapes me. I am missing the most important information: last modified date. And then also who modified it.

Eye-candy. The Gravatars on that page are an eyesore. Besides the fact that my web browser sends to your server a Do Not Track (DNT) header and Gravatar is a privacy-infringing tracking operation, it also slows down the page. Whether the slow down or the privacy infringement are acceptable is debatable, but performance wise SFweb is so much slower than hgweb that speed alone would be a good reason to send SFweb back to the drawing board. Please remove unnecessary third-party dependencies and eye-candies (fonts.googleapis.com) and make the page functional. The link to the committer's SF's page is superfluous.

Summarizing, the navigation in SFweb:
1- does not provide me with the information to make an informed and quick decision.
2- clutters my display with irrelevant stuff that consumes my time to sort through.
3- dump consumer-hostile, slow, privacy-infringing code on me.
=> is not something I want to deal with / use on a regular basis.


Things get even worse when trying to visualize individual changesets or changelogs.

The individual changeset loads fast on hgweb and is self explanatory.

When I get to the visualization stage on SFweb, e.g.
https://sourceforge.net/p/enblend/code/ci/89d381db54667d8bde4d18bfb5000c38f52db6b5/ it takes ages to load and I get an Error 500 message.

Maybe the error 500 is because on dependecies such as ajax.googleapis.com and fonts.googleapis.com. This is no place for eyecandy, and even less for tracking. I can't repeat often enough that my web browser sends to your web server a DNT header. Please honor it. Look at FreeBSD.org for a clean and neat implementation: if I send to that website the DNT header, I get a clean page. If I don't I get the page plus all the privacy-infringing code that I have agreed to receive.


Frankly, I do not see myself sending to a fellow developer a link to SFweb, knowing full well that I am sending them to a time consuming, cluttered, spyware-infested, malfunctioning URL. I will tell them to run hg view on the command line or some other local tool. SFweb makes SourceForge less relevant to me and developers like me who care about substance and privacy, not eye-candy.


  • Anonymous - 2013-01-16
    • labels: --> engr, nf-4832, nf-5622, nf-5623, nf-5624, nf-5625
    • status: unread --> assigned
    • assigned_to: Chris Tsai
  • Anonymous - 2013-01-16


    Thanks for this particularly well put and thought out feedback. I've run this by our engineering team for their feedback, and we've created a few tickets for improvements based on this, and also point you to an existing ticket:

    • [allura:tickets:#5622] - we now have a grouping page for multiple tools of the same type (eg., https://sourceforge.net/p/enblend/_list/hg), this ticket is to make that page more useful by providing extra metadata for example, the commit data (if you have other suggestions for useful metadata for that page, please chime in on that ticket).
    • [allura:tickets:#5623] - for improvements to the branches/tags UI
    • [allura:tickets:#4832] - we're confident that it's not Gravatar/Fonts that's causing the performance issues, however, we do acknowledge we need some performance improvements. This ticket is for gathering more data on what's causing the slowdown.
    • [allura:tickets:#5624] - for handling DNT in allura
    • [allura:tickets:#5625] - while we believe the 500 on changesets is likely due to the aforementioned performance issues, I've logged this ticket to be handled separately

    I'll let you know as these issues are addressed.

    Chris Tsai, SourceForge.net Support

  • yuv

    yuv - 2013-01-27

    Hi Chris,

    Thank you for showing "progress". With all due respect I think that SF is going in the wrong direction and that the nature of the tool that you are developing conflicts with my interests as a user and contributor. Today I receveid a new email notification from your tool that seems to be aimed at replacing the Hg standard post-commit email hooks. I logged on to the user preference page and was appalled by it. You do not need to know my gender, birthdate, country of residence to manage a code repository for me. And I do not need you to send me more / different emails from what I receive from the post-commit hook.


    This time I won't give you "well put and thought out feedback". I am voting with my feet and I am disengaging. I will use every opportunity to advocate projects move their code repositories away from SF unless SF makes a promise to:

    (a) never disable the stock web and email interfaces that come by default with Mercurial and other open source tools underlying its service;

    (b) let the project owner control whether the stock web and email interfaces or SF's own custom interfaces are used by default;

    (c) let the individual user override those defaults on a project by project basis;

    (d) respect individual users e-mail preferences (TEXT vs HTML) and let them opt out from marketing;

    (e) respect individual users DO NOT TRACK (DNT) preferences and refrain to send users with DNT set to any third party site, particularly to sites such as googleapis.com, gravatar.com, google-analytics.com that are known to mine data across multiple web properties.

    These are my issues, not the technicalities at the individual ticket level.

  • Anonymous - 2013-02-05
    • labels: engr, nf-4832, nf-5622, nf-5623, nf-5624, nf-5625 --> engr, nf-5622, nf-5623, nf-5624, nf-5625
  • Anonymous - 2013-02-12
    • labels: engr, nf-5622, nf-5623, nf-5624, nf-5625 --> engr, nf-5622, nf-5623, nf-5624
  • John Barrett

    John Barrett - 2015-10-07

    Durning a ticket review process I saw this ticket, so I apologize for the delay in my reply to this ticket. I think this is an old issue that has already been taken care of if I'm mistaken please let me know and I will take another look into your situation.
    SourceForge Support

  • John Barrett

    John Barrett - 2015-10-07
    • status: assigned --> fixed

Log in to post a comment.