Help with extension writing

[Matthew Watson]

OK, thanks to everyone for the help and suggestions and the feedback on
freenode#mercurial as well.

There were a few things I missed that made my life harder, particularly
relying too much on http://mercurial.selenic.com/wiki/MercurialApi rather
than the source for my information:

* I didn't realise you could get any filectx in the manifest by
changectx['file']: I thought it was only files in changectx.files()
* I didn't see filectx.parents(), filectx.ancestors() etc. This is just me
not scrolling down and looking harder!

I should add some doco and send you a patch, as when you are completely new
to the api, it's quite hard to figure out what you are being returned and
how one can use it, i.e. what the values in the manifest are, what the
linkrev is etc - there is little doco in the API and this added to my
confusion.

One last question: Sometimes when a file has 2 parents, we may want to find
the closest changectx mergepoint for the 2 ancestor revisions (I guess there
could be more than one, but there would be 1 that is closer or as close as
the others) - like changectx.ancestor(self, c2), but for descendants - there
doesn't appear to be one on changectx, is there something like this
elsewhere?

Thanks Again,
Matt

On 14 April 2010 23:48, Greg Ward <greg-hg at gerg.ca> wrote:

> On Wed, Apr 14, 2010 at 4:08 AM, Matthew Watson <mattw.watson at gmail.com>
> wrote:
> > We started off just calling the command line, but this resulted in
> > lots of calls to hg/python, so we figured an extension would be more
> > performant and have access to more information than we can easily get
> > from the command line.
>
> And you have finer control over what you pass in to hg and better
> ability to parse what you get out.  Python is a much nicer programming
> language then the shell, and Python data structures are much richer
> than strings.
>
> > We're also trying to make this is low maintenance as possible, so
> > trying to stay away from internals that might change over time as much
> > as possible (we have no control over what version of mercurial our
> > clients will use, but can recommend  versions that our extension will
> > work with)
>
> But you *can* specify a minimum version, surely?   I mean, don't make
> it 1.5, but you should be able to target (say) 1.2 or 1.3 without much
> difficulty.  It does mean you have to test your code with every
> version of Mercurial >= your chosen minimum; that's the cost of using
> the Python API.  But it forces you to write good tests, which is
> obviously in your long-term interest.
>
> Greg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100415/4b69f4f0/attachment.htm>