FOableVCSSPI195124

Versioning framework should be able to work via file objects

Contents


Problem Description

taken from issue issue 195124 - "For now there is a lot of java.io.File usage in versioning frametwork SPIs. This disallows adding versioning support for different file systems."

the c/c++ Remote FS gives access to files located on a remote host. Following problems have to be solved to make the VCS infrastructure available to filesystems other then masterfs (based on io.File).

RemoteFS and VCS interoperability

Make RemoteFS VCS friendly

it is essential for VCS modules to have a set of file relevant functionality provided by an "integrated" filesystem

  • file events - notify about file changes
    • beforeChange(file)
    • afterChange(file)
    • beforeCreate(file)
    • ...
  • file handling - let VCS plugins take over the execution of file operations
    • doDelete(file)
    • doMove(from, to)
    • ...
  • queries - let VCS plugins override file state, attributes, ...
    • canWrite(file)
    • ...
  • file annotations - annotate (by color and text) a given name representing a set of files - file names, as wel as physical and logical folders names in the IDE
    • String annotateNameHtml(String name, Set<? extends FileObject> files)
    • Image annotateIcon(Image icon, int iconType, Set<? extends FileObject> files)
    • ...
  • actions - provide actions for a given set of files. Used for main and context menu
    • Action[] actions(Set files)
    • ...

io.File based VCS infrastructure

  • vcs relevant file handling and events are provided by the friend maserfs api in masterfs/o.n.m.masterfs.providers which is based on io.File
  • the vcs spi operates with io.File
  • particular vcs clients operate with io.File

Remote execution

the particular vcs clients have to execute their commands agains files located on a remote host

client type / vcs system svn hg cvs git clearcase ade local history
commandline x (*) x x x
java native (io.File) x x x x
jni x

(*) deprecated. the svn cli client works properly only for svn <=1.6. Was hacked not to break on 1.7, but isn't maintained anymore.

General Queries API

VCS plugins call or implement queries from queries/o.n.api.queries

  • SharabilityQuery - called by vcs plugins - takes io.File as an argument
  • VisibilityQuery - implemented by vcs (plugins) - takes io.File or FileObject as an argument
  • CollocationQuery - implemented by vcs (plugins) - takes io.File as an argument


Possible solutions

RemoteFS and VCS interoperability

Use FileObject instead of File in VCS

simply replace io.File with FileObject in relevant VCS modules, and add a equivalent api to RemoteFS as it is now in MasterFS.

positives

  • sounds easy :)

negatives

  • VCS was originally designed to work on io.File level ("underneath" MasterFS and its FileObject(s)) as well as there is a contract between masterfs and VCS that there will be no synchronous reentrant calls into masterfs from VCS. This is actually a stopper, (or very difficult to solve in the best case). no more arguments needed.

Abstract from io.File and FileObject

  • design a bridge between VCS and masterfs so that VCS won't be directly depending on masterfs and can eventually run only with remote fs. Should be based on implementations of org.netbeans.modules.masterfs.providers.AnnotationProvider and org.netbeans.modules.masterfs.providers.ProvidedExtensions in VCS
    • use a new type to wrap io.File as well as FileObject
      • VCSFileProxy declared in VCS - until NetBeans runs on jdk 7 and nio.Path can be used
      • VCSFileProxy has to provide provide all file operations and convenience methods necessary for VCS - e.g. file creation relative to a path, conversion to io.File, FileObject, etc. ... For complete list see here
  • implement necessary parts in RemoteFS
    • VCSFileProxyOperations
  • rewrite VCS
    • use VCSFileProxy instead of io.File in the versioning (versioning.util) modules
    • enhance SPI so that it is also VCSFileProxy capable
  • rewrite current VCS plugins

negatives

  • TODO :)

positives

  • clean, extendable, doable, ...

responsibility

  • CND team will take care of the implementation necessary in RemoteFS
  • VCS & Jarda team will rewrite the VCS infrastructure and provide a new SPI based on VCSFileProxy
  • TODO what about the current VCS plugins
    • for more info about remote execution see bellow
    • TODO how much is it necessary at this point?
    • note that the suggested approach implies a possibly significant effort to rewrite the the current codebase

Remote execution

while we are at the moment not sure how to deal with remote execution of native java or jni based clients, the External Execution Support (extexecution) module seems to be already a good way to deal with remote execution for commandline clients.

As long a VCS plugin isn't based on io.File anymore and is able to obtain the remote FileObject for a wrapping file type suggested above, then all needed information is available to execute a VCS command in the files remote context.

responsibility

  • new VSC modules - up to the developer
  • current VCS modules - TODO
    • significant effort is to be expected

Queries API

evaluate the current state and make queries FileObject capable.

not exclusively a VCS issue. Also used/implemented by other subsystems in the IDE.

responsibility CND team should deal with this for the start, VCS team will adjust VCS modules when the time is right.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo