[PATCH] serve: automatically include local subrepos

[Mike Williams]

On 22/02/2011 17:13, Matt Mackall wrote:
> On Tue, 2011-02-22 at 09:43 +0000, Mike Williams wrote:
>
>>> Second, this patch doesn't fit in with the subrepo design philosophy.
>>> We make a point of NOT looking into changesets to figure out what
>>> subrepos are involved when we don't have a working directory context.
>>> For starters, there's no reason to think that there will be a uniquely
>>> relevant and correct changeset. There could be many on many different
>>> branches, and one or more of them could be buggy. Further, there's no
>>> reason to think those subrepos will be -Mercurial- subrepos.
>>>
>>> Thus knowledge of subrepos is strictly in the domain of clients which
>>> have working directories.
>>
>> I thought I had picked up the working directory but I see now I hadn't
>> sorry.  I also thought I had filtered subrepos to be mercurial ones
>> only, I must not yet understand what subrepo.status() returns.
>
>>> A more acceptable way to do this would be:
>>>
>>> - make the single-repo mode of hgweb a special case of hgwebdir
>>
>> Ok, will need to do more code reading.
>>
>>> - add a flag to the hgweb scripts to include recursively include
>>> subdirectories by default
>>
>> includesubrepos?  would there be an interaction with descend?
>
> You're still thinking in terms of subrepos. As I've explained above,
> this is wrong. A server _must be unaware of the whole concept of
> subrepos_. This is because subrepos are bound to individual changesets
> and not to the history as a whole. Thus the question of "which subrepos
> go with this repo" is meaningless in general. You can't answer this
> question without looking at ALL the changesets and then you may to get
> lots of contradictory answers.

I am coming off the back of a proprietary system that works in terms of 
tips of subrepos - the nearest equivalent I can think of is CVS modules 
but on steroids, projects using between 10 and ~150 modules.  Undoing a 
mindset of this after many years ain't gonna happen overnight.  For my 
sins I am driving the move to Mercurial at my company, possibly not 
ideal but there you go, but trying to get involved hopefully in someway 
will help with that.  Changing from date and time based to changeset 
based, and linear to a tree is going to blow some minds.

Your point about having to consider all changesets is sinking in.

> Instead the server should think instead in terms of "trees of
> repositories", serving up repo/ and all repositories under it from a
> filesystem point of view. Conveniently, hgweb already knows how to do
> this when running in its "hgwebdir" mode with the directive "repo =
> repo/**". This is more or less what you want, but it's not easy to get
> at using hg serve (you need to give it a --web-conf file)

That was my starting point.  Mads suggested the repo/** glob for picking 
up the subrepos as I felt essentially copying the contents of .hgsub to 
hg serve them was just wrong.  I know a bug fix related to that went in 
recently.

> So to fix that, my proposal is:
>
> - make single repo just a special case of directory mode, so that nested
> repositories are just a config option away
>
> - add a switch (--recursive) to serve so that we serve nested repos.

I can go with that.  Just gotta keep fighting the urge to say "it should 
just do it".

-- 
Mike