RFC: hgweb enhancements

[Tim Delaney]

On 19 April 2013 23:50, Augie Fackler <lists at durin42.com> wrote:

> On Fri, Apr 19, 2013 at 1:57 AM, Tim Delaney
> <timothy.c.delaney at gmail.com> wrote:
> > 1. Bugfix: allow parsing branch/tag/bookmark names from the URL if the
> name
> > contains a forward slash.
>
> This one sounds like a good bugfix to me, would like to see a patch.
>
> Might also be worth filing a bugzilla bug, as someone else might be
> willing to spend time on it.


I'll definitely be producing a patch for this one. I could do it this
weekend if it should go into 2.6, otherwise I'll hold off to next month.


> > 2. Using the revision specified in the URL for navigation links. For
> > example, if I requested http://localhost:8000/branch_name, the
> navigation
> > links would be:
> >
> > log: http://localhost:8000/shortlog/branch_name
> > graph: http://localhost:8000/graph/branch_name
>
> I think I'd be strongly in favor of this, as I could follow a link to
> @, and then refresh would do a useful thing.


Yes - that's basically one of my use cases as well (although in my case
it's a particular named branch head), although the one that prompted me to
implement this was that going to http://localhost:8000/shortlog/ and then
clicking graph would have you stuck on a revision. Annoyed me every time.
With this change it will go to http://localhost:8000/graph/.

Does http://localhost:8000/@ work? It doesn't on the machine I'm currently
on, but its mercurial is slightly out-of-date. I don't use bookmarks so
hadn't even considered this case. http://localhost:8000/?node=@ does work
so it probably just needs some URL parsing help.

> 3. Branches, tags and bookmarks in changelogs and changesets are links to
> > the shortlog for that branch/tag/bookmark, rather than just plain text.
>
> Hm, not sure how I feel about that, but maybe (linking the word
> default everytime it appears strikes me as potentially annoying).
>

This is actually something I've only implemented in the last couple of
days. It feels quite natural to me for navigating around.

Visually it's the same as before - I've moved the class="..." to the link.
And in the case of default, it's hidden except at the branch head in the
changelog. Well, actually in *my* hgweb it's shown everywhere, but I
wouldn't even suggest submitting that change ... (since I use named
branches so extensively, I like to always see the branch name).


> > 4. The branches, tags and bookmarks in their respective pages have the
> > branch/tag/bookmark name in the link, rather than the revision they
> > currently refer to e.g. http://localhost:8000/shortlog/tip
>
> +1 from me
>

The forward slash bugfix above is a prerequisite for this in my team.


> > 5. The tags and bookmarks page entries link to shortlog rather than rev -
> > consistent with the branches page, and more useful IMO with the link
> being
> > to the tag/bookmark name.
>
> I think that sounds good, but I'm not as strongly in favor as the others.


Yes - this is definitely a to-taste thing. I'm actually thinking of making
it go directly to the graph for myself, since that's what I use most ...

One thing I've been thinking about is whether I can produce a page with
just the ancestors of a revision. Most of the time when I'm looking at the
changelog I'm only interested in the history of a particular branch, and
anything else is just noise. In that case it might make sense to have the
branch, bookmark and tag links go there. Or maybe add a link on the
log/graph pages to filter out anything that's not an ancestor.


> > 6. The branches, tags and bookmarks pages have an atom link next to the
> node
> > e.g. http://localhost:8000/log/tip?style=atom
> >
> > 7. Reordering of the parents from graphmod.dagwalker to keep branches
> > vertical as much as possible. The parents are sorted so that if there is
> a
> > single parent on the same branch as the changeset, that parent will be
> > listed first. If both parents are on the same branch, the one with the
> lower
> > revision is sorted first.
> >
> > Visually this makes it appear as though newer revisions in the repo are
> > merged into the existing branch, which conceptually works well for me.
> >
> > 8. Adding links to the branches, tags and bookmarks for each changeset in
> > RSS and atom feeds.
>

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130420/7fd68b6a/attachment.html>