For now there are a lot of java.io.File usage in versioning frametwork SPIs. This disallows adding versioning support for different file systems.
sounds like you want to write a new VCS system which is suposed to work with file objects not based on io.File. right?
the api/spi is designed to work with io.File. where is the defect here?
Agreed, this is an enhancement rather than a defect.
And sure this isn't for 7.0
The real use case is as follows: CND project allows remote source roots, i.e. these source roots' file objects do not correspond to java.io.File. Such projects lack VCS support.
In subsequent releases we'll need to support at least some VCS providers for such projects. But it isn't possible unless we change/extend existent VCS framework and its SPIs.
this, of course, also affects some other api-s between vcs and the rest of the IDE (masterfs, ...)
> to support at least some VCS providers for such projects
"some VCS providers" stands for the vcs systems we already support? or do you have something else in mind?
That might be ADE and probably some of existent providers as well.
another probable hook which might be needed for remote is:
- external provider of VCS information for files, folders, ...
Using it we can execute command line tools remotely and provides needed info for IDE
from the few statements we got until now it's quite hard to tell what we are supposed to do about this issue. Simply stating that you need the SPI to be FileObject able and that you need some kind of a hook isn't enough. As well as simply replacing io.File with FileObject won't work for several reasons. We probably have to change a lot in the current vcs module(s) and we would like to have a bit more information before we do that.
So before we start to do anything with the VCS SPI, it would be good to lear more about the remote filesystem and what actually are your intentions with the new api/spi. lets describe and discuss the whole problem here - http://wiki.netbeans.org/FOableVCSSPI195124
seems to be fixed