hgweb page with hg log -b <branchname>

[Johan Samyn]

2009/12/28 Nicolas Dumazet <nicdumz at gmail.com>:
> 2009/12/28 Johan Samyn <johan.samyn at gmail.com>:
>> 2009/12/24 Matt Mackall <mpm at selenic.com>
>>>
>>> On Thu, 2009-12-24 at 14:09 +0100, Johan Samyn wrote:
>>> > Hi,
>>> > I plan on adding an extra link "revisions" to each branch line on the
>>> > branches page in the hgweb interface. It should produce a new page
>>> > with the results of a "hg log -b <branchname>" command (layout based
>>> > on the shortlog page).
>>>
>>> Sounds good. What's your plan for extending our URL syntax to include a
>>> branch name?
>>>
>>
>> I'm actually working with '.../branchlog/<shortnode>/<branchname>'.
>> The corresponding function branchlog() in hgweb/webcommands.py
>> extracts the 'file' part of the req.form as the branchname.
>
> I think that you _have_ to use a new function to avoid ambiguities
> between filenames and branchnames, so branchlog sounds good to me.
Thanks for confirming.

> But about information hierarchy, I would rather have this scheme:
>   branchlog/<branchname>/<shortnode>
> Any issue with that one?
> It's much more logic to me: after all, we will be examining changes
> along a branch, and not branches associated with a particular node.
> When paging through a branch, we will get branchlog/foo/hash1, then
> branchlog/foo/hash2, etc... Only the last part of the URL changes,
> which is more intuitive.
I have no problem with "branchlog/<branchname>/<shortnode>", so I
started using that one.
(In fact I did not have very much of a clue about this part of the
feature. I just looked at existing code to start.)
The csets will be shown most recent first, as on the shortlog page.


I'm struggling with calculating the navigation indications at the
bottom right of the page. As a branch - except for default - doesn't
start at the 0 rev, the page calculation as it is done for shortog is
not very accurate here. I'm beginning to think that if I want to show
a navigation line at the bottom right similar as for the other pages,
I'll have to read (= count) all the csets for the branch upfront. But
that is exactly what all the other functions in webcommands.py avoid,
because it's costly.
Options I see are :
1) Indeed read upfront, and get a correct counting for using the
existing navigation links according to the size of the branch.
2) Show 'first - prev - next - last' links, each as appropriate to
where we are in the branch, with pages of 50 csets each or so.
What's your view on this one ?

It surprised me that I could not just reuse some standard log-command
logic (passing it the '-b <branchname>' option and some counter
arguments), and present the returned results in the web page. IMHO I
think the standard log-command logic should be the best of all - in
all aspects - within Mercurial for providing this type of data. But
every function in hgweb/webcommands.py does things it's own way. Maybe
I'm missing a good reason for that ? Perhaps it is the fact that
webcommands.py functions read just enough data to display a page, and
no more ? Then I still don't see why the log-command logic could not
have been providing a generator function, just like the functions in
webcommands.py. (Please don't take this as pure criticism. As I said,
I could be missing something.)

Johan