[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