questions about post_change_branch_tip hook

Alexander Belchenko bialix at ukr.net
Thu Feb 11 08:53:54 GMT 2010


John Arbash Meinel пишет:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alexander Belchenko wrote:
>> I have some question about post_change_branch_tip:
>>
>> 1) Documentation on
>> http://doc.bazaar.canonical.com/test/en/user-reference/hooks-help.html#post-change-branch-tip
>> said this hook triggered for push, pull, commit, uncommit. What about
>> update command for bound branches? This hook should be invoked for the
>> update too, IIUC? Can you reflects this in the help, please?
>>
> 
> It is triggered any time the *branch* tip revision changes, which may
> not happen for 'update' (if it only updates the WT, etc). I think adding
> an 'etc' is reasonable, as I don't think we catch all of the cases by
> just listing commands we think about.
> 
>> 2) I'm thinking about how to store previous branch tip for pull/update
>> operations so I can implement something like whatsnew command to see the
>> log (and/or changes) introduced by the last pull.
>>
>> Question: how can I know in the hook which exactly operation updates the
>> tip? ChangeBranchTipParams has no context for this. Should I use
>> post_pull hook instead? It seems very old, I hope there is no plans to
>> deprecate/remove it?
> 
> We generally don't propagate information about what command is running
> down to the lower layers. It does happen that sometimes Branch.pull() is
> called versus Branch.update(), but Branch.update() could be defined in
> terms of Branch.pull() (I think they currently re-use a common helper,
> but they could easily be layered differently in the future.)
> 
> I don't really know what you want for 'missing' that is different from
> 'bzr missing'. Or at least a variant of that. You may want to define the
> use cases.

Here is use case, something similar have asked for Explorer itself:

while working with big scmproj-based project I do update all components 
(branches) at once. If I pull changes from other members of my team I 
may want to review them post factum or just to get familiar with new 
code. So I do bzr project-update for 15 components and many of them pull 
in new revisions. If I will store which part of the local history is the 
new revisions I can more effectively review only those revisions and 
their changes via qlog/qdiff. Something like that./

> 
> I believe that 'ChangeBranchTipParams' *does* include the information
> about what revision the branch was at before the update, and then what
> it will be after the update. You could just save the 'before update'
> revision, and use that for 'whatsnew'.

That's basically my idea I'm thinking about.

> 
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkty7+YACgkQJdeBCYSNAAMaCQCgu0UzY+p7Bo79Qx8E9IFgh8JO
> xtEAoM2eRH3CZMogfsSWHDssY42dj5gG
> =NWAz
> -----END PGP SIGNATURE-----
> 
> 




More information about the bazaar mailing list