it would probably be a good idea to add such an API to subversive.
In my case using a not subversive specific API would be even better, as it would prevent me from tying my code to a specific team provider.
The Eclipse Logical Model Integration API might be a way to do that.
However, if you're not planning to add support for that API anytime soon, using a subversive specific API would be the only option.
Adding it in either case would probably be sensible anyway.
I haven't looked at the subversive source yet so I can't really say anything about a good location or interface for such an API. The general idea is that certain applications/plugins will need a degree of control over team provider actions.
Some examples from our application:
* for each java source file a number of additional support files are automatically created. They are never modified by the user directly but reflect the state and editing history of the corresponding source file. The java file and the support files create a single entity which must at all times stay in sync.
** directly before a commit the latest version of those support files need to be written to disk.
** whenever a new source file is checked into the repository, the corresponding support files need to be added too
** whenever a source file is checked out of the repository, the corresponding support files need to be checked out too
** it must not be possible to commit only the source file or only the support files
** whenever support files are checkedout/updated from svn they need to be parsed and the information stored within them is then internally stored and updated by our application
** in case of a conflict/merge special merge code needs to be executed to handle the merging of the support files.
As you may notice most these requirements are pretty much what the Eclipse Logical Model Integration API is aiming at. But all of them could also be covered by a couple of listener APIs which would allow 3rd parties to hook custom code into the subversive SVN processing.
The key points would probably be hooks on the events listed in my first post. For the "before" hooks it would be important to make sure that any modifications done during that phase are taken fully into account for the event. I.e. if listener code in a "before-commit" hook modifies a file or adds new files, then those would need to be taken into account for the commit.