On 06.08.2009 00:01, Thomas S. Trias wrote:
> We've actually encountered a case where it would be useful to have
> the list of files themselves (along with their checked state). In
> our case, we are relying upon the user to re-validate after checking
> / un-checking files in the commit list. We are not writing bug
> tracking per se; our plug-in checks various properties and provides
> suggestions / fixes if the properties are missing or invalid.
>
> Using the hooks was not as friendly an integration mechanism, so we
> ended up using window messages to gather information and to refresh
> the commit window if necessary. We realize that this is a rather
> brittle solution, but our alternative was to add a new plug-in
> architecture to TortoiseSVN.
>
> I agree with one of the issues in Flyspray that suggests that there
> be interfaces for the various hooks. I also think that providing a
> call-back object and / or event source COM interface to a new
> iteration of the IBugtraqProviderXXX interface / TSVN type library
> would go a long way to providing flexible extensibility.
You mean a notification to the provider object for every change in a
checked state?
>
> As time goes on, this will become more urgent for us, so we will end
> up adding this feature ourselves eventually. We are more than
> willing to give the result back to the community, but cooperation /
> collaboration would be ideal during the development process.
Could you maybe write down your requirements in detail? Maybe even down
to the level of API functions you would need and how they should work?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2380727
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-06 10:07:12 CEST