[MERGE] Add add_commit_revprops hook so plugins can set their own revprops.

[Alexander Belchenko]

This patch raise adjacent question in my head: may I use any arbitrary
revision properties for my own needs? It won't screw up anything important
in the bzr itself?

I'd like to use special [hidden] revision property as additional id of commit.
So then I can use it in my scmproj plugin to find common commits in several
components.

I wonder how cvs2svn detect common commits in the CVS history.
I know that cvsnt has stored special unique id for each commit
to easily find common commits. Perhaps cvs2svn uses approximation
by exact match of commit message and commit time hit the
same short range?

James Westby пишет:
> On Thu, 2009-02-19 at 20:53 +0000, James Westby wrote:
>> Hi,
>>
>> It's not currently easy for plugins to add their own revprops
>> to the upcoming commit, so I implemented a hook to allow it.
>>
>> The alternative to a separate hook would be making revprops
>> an attribute of MutableTree so that plugins can use start_commit
>> to do it.
> 
> I'm not sure about this myself.
> 
> I just wrote an implementation of commit_message_template in
> bzr-builddeb. Getting passed the Commit object here is quite
> nice, as it gives you all the information you need, such as
> specific_files and excludes for the commit.
> 
> My use case for this is making use of the structured information
> we put in debian/changelog when we fix a bug. I patched "debcommit"
> to pass --fixes, but it would be nice to have it happen automatically
> on "bzr commit".
> 
> I don't think the revision properties should be added if you
> "bzr commit -x debian/changelog", but you can't work this out
> given just the working tree.
> 
> We could extend the hook signature to include more of this information,
> but that's going to be fragile.
> 
> Would it be feasible to follow the message code and add a 
> revprops_callback to Commit?
> 
> Thanks,
> 
> James
> 
> 
>