Page 1 of 1

SVN Commit/Update/... Listener

Posted: Thu Jun 28, 2007 11:12 am
by exp

I am working on a plugin which needs to be aware of the user's SVN actions. Is there any way to register some kind of event listeners with subversion in order to receive notifications for SVN actions? Or is there any other way of doing this?

I.e. if possible I'd like to have some of my code executed at the following points:
* directly before commit
* directly after commit
* directly before update
* directly after update
* directly after checkout
* on merge conflict/...

H. Meyer

Posted: Mon Jul 09, 2007 2:06 pm
by Alexander Gurov
Dear H. Meyer,

At the current moment Subversive does not provide correponding interfaces. So, this is a point to improve plug-in functionality. Could you please provide more information about API's that is required by your task?

Posted: Thu Jul 12, 2007 10:27 am
by exp

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.
That means:
** 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.

H. Meyer

Posted: Thu Jul 12, 2007 1:13 pm
by Alexander Gurov
Thank you very much!

We will check this point more precisely. At the current moment I see it is Eclipse 3.3 specific API's in most cases. This mean that we should make new development branch in order to support it because the current Subversive plug-in should stay compatible with Eclipse 3.2.

Posted: Fri Jul 20, 2007 6:52 pm
by exp
IIRC the API was introduced with Eclipse 3.2 and it seems that some modifications were made in 3.3, but I didn't find much documentation about that.
Maybe it would be possible to implement the 3.2 part of the API in the stable subversive branch?

What are your long term release plans? Will there be two stable versions of subversive at some point, one for eclipse 3.2 and one for eclipse 3.3 or will no eclipse 3.3 features be part of any stable release?

H. Meyer

Posted: Fri Nov 16, 2007 5:10 pm
by exp
Alexander Gurov wrote:At the current moment Subversive does not provide correponding interfaces. So, this is a point to improve plug-in functionality. Could you please provide more information about API's that is required by your task?

As it is probably pretty unlikely that real progress on the logical model integration will be made in the short term, how would I best go about to workaround the issue?

Specifically, how can I detect which files are going to be comitted or updated by a user action?

I was wondering about the "Commit" extension point. Maybe I could provide a "fake" commit dialog via an ICommitActionFactory which just delegates to the default dialog but keeps track of the resources which are part of the commit?

I could also register a resource change listener which keeps track of resource changes with flag CONTENT as each commit is modifying some team private files inside the resource tree which will trigger a resource change event for the parent folder of any file which was committed. However, in that case I would need to find out which file in a folder was affected.
One possible approach would be to check the revisions of the files and compare them against some stored values. But how can I get the revision data for an IFile?

My first thought was to adapt the IFile (or IResource) to IRepositoryFile (or IRepositoryResource). But unfortunately subversive does not register an AdapterFactory for this conversion. Wouldn't it be sensible to do so? Or is there any other way to get that data (besides parsing the team private data files myself)?

The best approach would probably be some listener API in the subversive core plugin which allows to register a listeners for different event types. Similar to how eclipse handles resource change listeners. Possible event types could be: pre-commit, post-commit, pre-update, post-update, pre-checkin, post-checkin, pre-checkout, post-checkout, pre-disconnect, post-disconnect, ...
Where the most important events would be the pre-/post- commit and update event types.

In general there seem to be some areas where subversive could provide more access to its internal state in order to allow better coupling with other plugins which are dependent on receiving real-time SVN status information.
How is the development of subversive handled at the moment. If I were to submit detailed recommendations or even a non-invasive patch. Are there realistic chances that such changes would find their way into a stable subversive release within a couple of months?

Hans Meyer

Posted: Mon Nov 19, 2007 2:35 pm
by exp

it seems that approach via an adapter factory is not the standard way for doing this. At least the eclipse CVS plugin doesn't do it this way either.

However, there is a specific API (RepositoryProvider, RepositoryProviderType, Subscriber, SyncInfo) which allows repository provider independent access to a Subscriber instance which can then be used to register listeners and to acquire synchronisation status information for a resource.

It seems as if the Subversive SVN plugin does not fully implement this API. Why is not implemented?
It only delegates to the super implementation, which will alwas return null.
Shouldn't you be returning a Subscriber instance?

Subversive SVN Plugin code:

Code: Select all

   public Subscriber getSubscriber() {
      // TODO Auto-generated method stub
      return super.getSubscriber();

CVS Plugin code:

Code: Select all

   public Subscriber getSubscriber() {
      return CVSProviderPlugin.getPlugin().getCVSWorkspaceSubscriber();

H. Meyer

Posted: Wed Nov 28, 2007 9:32 am
by exp
Should I post this request on the subversive-dev mailing list?

Hans Meyer

Posted: Thu Nov 29, 2007 9:45 am
by Alexander Gurov
Dear Hans,

Thank you for your tips. Corresponding task already posted to Subversive Bugzilla at

We will start implementing all Bugzilla tasks including the API usage enchancements after migration to is complete (this should be soon).
So, in the future you can provide all your proposals at

Posted: Thu Nov 29, 2007 11:51 am
by exp
Thanks :o)

Any chance that the small issue with

might be fixed soon?
I assume that this is a very trivial issue compared to implementing all the Eclipse Team APIs. But it would already help us a lot for the project we're currently working on.

Hans Meyer