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 (http://www.intellij.net/forums/thread.jsp?forum=23&thread=27970&tstart=0&trange=100):
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 (http://www.intellij.net/tracker/idea/viewSCR?publicId=4668 & http://www.intellij.net/tracker/idea/viewSCR?publicId=4256). 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 (http://www.intellij.net/tracker/idea/viewSCR?publicId=2751). 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.