my first-ever extension: hgsubrepo

[Andrew Petersen]

On Mon, Jul 12, 2010 at 3:21 AM, Martin Geisler <mg at aragost.com> wrote:

> Nicolas Dumazet <nicdumz at gmail.com> writes:
>
> > Hello!
> >
> > 2010/7/12 Andrew Petersen <kirbysayshi at gmail.com>:
> >
> >> I've created a very simple (and pretty dirty) extension to allow for
> >> batch-processing of multiple subrepos, located here:
> >>
> >>   http://bitbucket.org/kirbysayshi/hgsubrepo/src/tip/subrepo.py.
> >>
> >> It's my first mercual extension, as well as the first time I've even
> >> looked at Python.
>
> Very nice!
>

Yeah, thanks so much for the changes! There are a lot of objects/commands
you used that I haven't seen. Is there any documentation as to what else
exists? All I found was the MercurialAPI wiki page, and the basic Extensions
page (on how to make an extension).

I tried running the extension, and there are a few errors. One such is that
when running hg subrepo -u, line 71 errors: AttributeError:
'localrepository' object has no attribute 'update'. If someone chimes in
with where the documentation for what IS in the localrepository object, I
can probably fix this myself. I'm guessing maybe just look at the source?

Right, this is one point.
>
> Another point is that we support subrepositories of different kinds:
> Mercurial, Subversion, and hopefully soon also Git.
>
> I think the right architecture for this is to expand the classes in
> mercurial.subrepo with new methods and then just iterate over the
> subrepository objects and call the corresponding method. I imagine
> making an abstract base class which raises NotImplemented for all calls,
> and the high-level caller can then decide for himself just how fatal it
> is that a given subrepository does not support the requested operation.
>
> The fetch extension would then be the one that adds fetch methods to the
> subrepository classes where it makes sense.
>

I agree completely. To be honest, I hadn't even thought of other types of
subrepos than hg subrepos. I can't wait to see some functionality like this
in the actual subrepo extension, along with basic status. One thing that I
don't think is necessary is any sort of recursive functionality, since the
parent repo should deal with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20100712/872e68ca/attachment.html>