[PATCH 1 of 1 stable rfc] hgweb: handle paths with wildcards expanding in a repository root

Mads Kiilerich mads at kiilerich.com
Thu Feb 3 19:57:58 CST 2011


Matt Mackall wrote, On 02/03/2011 06:04 PM:
> On Thu, 2011-02-03 at 03:33 +0100, Mads Kiilerich wrote:
>> Do you agree that this is how it should work?
>>
>> Or should 'repo' be excluded when expanding 'repo/*'? That could make sense,
>> but it wouldn't be very convenient.
>>
>>
>> # HG changeset patch
>> # User Mads Kiilerich<mads at kiilerich.com>
>> # Date 1296700431 -3600
>> # Branch stable
>> # Node ID 0497e8f94992e481eca3abb773b2501cf28a906a
>> # Parent  5fc7c84ed9b0ae9c3b9d16214db147405627d7dd
>> hgweb: handle paths with wildcards expanding in a repository root
>>
>> There was a trailing / too much when the wildcard expanded to nothing.
> Huh?
>
> Much like the subrepo path munging, I've long said that hgweb path
> handling needs to be a doctest for clarity and testability.

hgwebdir_mod.findrepos is build around a util.walkrepos and thus isn't 
suitable for a doctest. Some refactoring could make it possible to add 
doctests for the part of the function I touch, but it still wouldn't 
test that the actual request processing based on the output of walkrepos 
and findrepos really works. It is hard to come up with tests that tests 
anything interesting and not just prevents future refactorizations. The 
code is already tested quite thoroughly by test-hgwebdir.t.

(This is all good arguments for why the existing test suite is good even 
though (and because) it isn't unit testing. More unit/doctest of low 
level functions that are pure and used in many places or self-contained 
classes could be fine, but I don't think it is relevant here.)

However ... here you are ... patches has been sent.

The question remains: How should hgweb configured as 
'paths.repo=/repo/*' work when there is a repo in '/repo'? Should 
'/repo' be ignored because it doesn't match '/repo/*'? Or should '/repo' 
work? Right now '/repo/' is announced but doesn't work.

/Mads




More information about the Mercurial-devel mailing list