[PATCH 2 of 2] localrepo: extensibility points for pull
Gregory Szorc
gregory.szorc at gmail.com
Tue Jul 8 21:20:31 CDT 2014
On 7/8/14, 6:47 PM, Augie Fackler wrote:
> On Mon, Jul 07, 2014 at 08:43:07PM -0700, Gregory Szorc wrote:
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1404790424 25200
>> # Mon Jul 07 20:33:44 2014 -0700
>> # Node ID daa7b9b126b9ef4bbe66e1a029e01eccdc57ac00
>> # Parent 30333e516874716b8d9b41450282d1f22b87eba1
>> localrepo: extensibility points for pull
>
> Can you enlighten me on some of the (nefarious?) plans you have for
> these functions?
>
> I suspect it has to do with code review functions.
I wrote 2 extension in the past few weeks that needed to hook into "post
push" and needed access to the pushoperation. 1 was code review. I
needed to see which changesets were pushed so I could initiate/update a
code review against those changesets. The other was an extension that
updated Bugzilla when a push was performed. Again, I needed access to
the changesets that were pushed. In both cases, I had to wrap
exchange._pushbookmark because it happens after the remote transaction
has closed and has access to the pushop. Hacky.
For pull, I initially thought that you didn't need these hooks: you
could wrap localrepo.pull and get what you need. But having access to
pulloperation makes the lives of extensions easier. For example, if you
want to perform post-pull processing of incoming changesets, your
wrapped localrepo.pull must stow away a reference to the previous tip
and then iterate oldtip:newtip. I'm not embarrassed to say I've
introduced a bug or two due to an off-by-1 error in range(). IMO it's
much easier to iterate pullop.remote. (It's worth noting that I /think/
I ran into issues hooking incoming and changegroup because these changes
could get rolled back and the transaction API didn't (still doesn't?)
offer a facility to intercept rollbacks to recover from this.)
I don't have any explicit use cases for pull extensibility in mind.
Although I may retrofit an existing extension or two because I would
rather look at a pulloperation instead instead of infer it from before
and after state. pushoperation and pulloperation are definitely more
pleasant to deal with. So much easier to understand than the full API of
localrepo.
More information about the Mercurial-devel
mailing list