VCS Open API restrictions

In several threads we have talk about the limitation of not having the list of changes before check in.

I really like the current protocol since it handles a lot for me, however I believe in certain circumstances it is getting in the way. Having a simpler straight-forward way to handle check in would bring more possibilities IMHO.

Right now: AbstractVcs has methods that gets called for each type of modification as part of the Check In Project action. There is no way to get the list of modification in full at that time or prior to that.

Proposed solution: Keep the current way but have another lower level alternative which would require more work from the plugin but allow more flexibility: AbstractVcs.getModifications() that would return the list of modifications with their statuses.

Directoy deletion (
Since there is no visibility from the plugin that a file is being part of a tree that is being deleted, plugin developers have to implement workaround that amounts to hacking. Deleting the top directory is the only thing needed to be done in most modern VCSs .

LVCS traversal is not enough since it doesn't have deleted files ( & If we had a way to get from the VFSManager or the AbstractVcs[Helper] the list of changes (with their statuses) this problem would be solved

New statuses and VCS plugin assigning status ( With the new FileStatusProvider a plugin can tell IDEA a file VCS status (This is GREAT btw). If it would now be the responsability of the plugin to handle statuses on Check In Project, a plugin could register its own statuses since it would free up IDEA from knowing what to do about them. A template method pattern could still be used if a plugin could register a handler with the new status type.


Comment actions Permalink

Hi, Jacques!
Sorry for delay.
I'm going to attend VCS OpenAPI in a short time.
I'll take into consideration all your remarks.
I'm trying switch AbstractVCS to the system of providers. So I would like add ModificationProvider instead of getModifications() method.
Could you describe how you see "Modification" interface?
It has to provide information about change and virtual file. What else?

Comment actions Permalink


I am sorry for the delay. I have already reported a ITN problem I have with Outlook express which apparently misses messages. Apparently your message was missed. In addition I didn't get an email notification.
Very weird and annoying in this case because VCS Open api issues are very dear to my heart.
I am surprise Erb did not jump in however since he was the originator of some of these.

Modification interface, let's see
Are you planning on providing a open status interface where plugin can register their own? That might change whether to do the following.

I would have 2 subinterfaces of Modification


new filepath
new name

Maybe Movement and rename could be combined. Same thing for AbstractVcs providers BTW. It would clean up the interface nicely (I do not know of any VCS that differentiate move and rename).
It would be great if the userdata could be saved so a plugin could store specific attributes between sessions (file specific check in comments, branch info...)

Sorry again to have been a little "on edge" about my perception of your lack of response in my other posts. If I had known you posted here I would have responded the SAME day!
Hopefully this will be the beginning of a constructive conversation. If you have time could you also comment on my other thread

Thanks for answering. It is so good to get heard!


Comment actions Permalink

All providers so far are extension points right?
Would this fit more in the AbstractVcsHelper or are you going to migrate everything that is in the AbstractVcsHelper inside the AbstracVcs now that it is an class?
As much as possible I would still like separate interfaces/classes with cohesive responsability like your provider design provide.

This modifications should be available anytime: during editing session, before and after commit dialog i.e. excluded files removed from the change list after commit dialog returned.


Comment actions Permalink

Sorry for offtopic, but ...
If you look at date of Olesya post you will see that the it one month and one day older than yours. And watches of forum expires in 30 days and removed. That's why you don't recieve this notification message and probaly others.
May be bug report post in forum should be marked as long lived watches and notifications? If so we can post request in ITN tracker.


Comment actions Permalink

To clarify what I said, I see 2 usages:
1) VCS controlled modification management. cvs2 seems to be like that since it will pick the current cvs state of project files.
2) IDEA controlled list of modification. In that case it is pretty much like 1) with LVCS as the VCS.
One thing that need to be fixed is that VCS OpenAPI doesn't take external changes into account (anymore. Until 813 there was a hack to go around this).
LVCS detects changes made outside of IDEA. This needs to be optionally propagated to the list of modification (thing that the EAP no longer do). Additionally Modifications may need to be flagged as External Changes or IDEA Changes so a plugin can sync up external changes with their VCS.



Please sign in to leave a comment.