[PATCH] Allow hgweb.config [collections] to also report mq patch repositories

B Thomas bjthomas3 at gmail.com
Thu Mar 8 08:36:43 CST 2007


Hi,

That's a fair point, so I started exploring other alternatives.  The
capability provided by this patch is far too valuable (to me, at least) to
just walk away from it.  So, I started exploring a bit. However, I'm quite
limited in my Python abilities and  Mercurial familiarity. So, let me
suggest some ideas and get your reaction.  I have spent some time exploring,
but haven't come to any overwhelming "this is the answer!" solutions.

- I haven't been able to find a simple method to determine if an extension
is loaded.  The idea would be to detect mq as a  loaded extension, and have
walkrepos return the patch directory name if so.

- always check the entire tree for ".hg".  That was one of my initial
approaches (before the patch), and it's waaaayyyyy too long and expensive.

- I thought about adding something to [collections], but that doesn't appear
really feasible

- use an environment variable. I got this idea from the HGENCODING
capability.  Simply check for SERVE_MQ_REPO,
or more flexibly . attach "MQ_REPO_DIR" as a suffix.  This is easily set in
the same fashion as HGENCODING.  The default is none, which means that you
have to enable it to get it to work. That would seem to be a plus

I'm currently leaning towards the last approach, but wanted to get some idea
if this is closer to acceptable, of if it spawned some other, better, idea.

Thanks !
-b


On 3/4/07, Alexis S. L. Carvalho <alexis at cecm.usp.br> wrote:
>
> Thus spake Ben Thomas:
> > # HG changeset patch
> > # User Ben Thomas <bthomas at virtualiron.com>
> > # Date 1171545001 18000
> > # Node ID 9808688a12067cfff303870fca0f9eb7432d3e76
> > # Parent  e9fe2b12799cb1f5fd84188df4babeaf2e0af50c
> > Allow hgweb.config [collections] to also report mq patch repositories
> >
> > Extend the walkrepos function to also return an mq patch repository
> > path (if it exists). walkrepos, in util.py, appears to be used only
> > in processing the [collections] capability.
> >
> > Without this change (so far as I can tell), it's necessary to
> > individually list every patch repository. This can be
> > painful. For instance, I currently have 34 repositories, each with
> > their own associated mq patch repository. Keeping this straight
> > and up to date is more easily done with [collections] than with
> > individual pointers.
>
> Not sure about this one - I can imagine somebody not wanting to export
> his patch repos, and I'm pretty sure mpm would like to avoid adding
> special cases just for mq (or any other extension for that matter)...
>
> Alexis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.selenic.com/pipermail/mercurial-devel/attachments/20070308/3c64fdf0/attachment.html


More information about the Mercurial-devel mailing list