RE: Re: IBugTraqProvider2: repository root

On 2009-08-06 01:06:59 PDT, Stefan wrote:
> 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?
>

In a nutshell, yes; using COM event classes (which are just specialized IDispatch implementations), there is already a nice mechanism for subscribing to certain events (like a change in a list view or list view item). Essentially, the methods in the new plug-in interface (if it is so general, does naming it IBugtraqProviderXXX still make sense?) would pass in a call-back object that is the event source and that has useful methods and properties for gathering and setting information related to the commit; updating information via the call-back avoids issues where the state in the commit window drifts from the state manipulated by the plug-in. Passing in a call-back object would also limit the amount of information that would need to be passed to methods in the new interface, since the information could be gathered easily from the call-back object itself. However, in order to keep things simple for developers who do not need the event-driven model, there should still be methods in the plug-in interface for
each step of the way (e.g. initialization, configuration, activation of a UI element associated with the plug-in, pre-commit, post-commit, etc.).

> >
> > 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?
>

Definitely. I have another project calling my name today and tomorrow, and I am traveling Monday, but I can revisit this early next week. Given a flexible plug-in architecture, it is quite possible that TSVN can focus more on keeping up-to-date with SVN and improving existing features, and less on providing limited use behavior. :-)

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2380923

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-06 18:19:16 CEST